ETSITS 102 695-3 V8.3.0 



(2012-12) 




Smart Cards; 

Test specification for the Host Controller Interface (HCI); 

Part 3: Host Controller features 

(Release 8) 



Release 8 2 ETSI TS 1 02 695-3 V8.3.0 (201 2-1 2) 



Reference 



RTS/SCP-00HCIHV830 
Keywords 



smart card, terminal 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2012. 
All rights reserved. 

DECT™, PLUGTESTS™, UMTS'^" and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 
2QppTM ^^^ LTETM are Trade Marks of ETSI registered for the benefit of its Members and 

of the 3GPP Organizational Partners. 
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association. 



ETSI 



Release 8 3 ETSI TS 1 02 695-3 V8.3.0 (201 2-1 2) 



Contents 



Intellectual Property Rights 7 

Foreword 7 

Introduction 7 

1 Scope 8 

2 References 8 

2.1 Normative references 8 

2.2 Informative references 9 

3 Definitions, symbols and abbreviations 9 

3.1 Definitions 9 

3.2 Symbols 9 

3.3 Abbreviations 9 

3.4 Formats 10 

3.4.1 Format of the table of optional features 10 

3.4.2 Format of the applicability table 10 

3.4.3 Status and Notations 10 

4 Test environment 11 

4.1 Table of optional features 11 

4.2 Applicability table 12 

4.3 Information to be provided by the device supplier 14 

4.4 Test equipment 14 

4.4.1 Measurement/ setting uncertainties 14 

4.4.2 Default conditions for DUT operation 15 

4.4.2.1 General 15 

4.4.2.2 Status of UICC interfaces 15 

4.4.3 Minimum/maximum conditions for DUT operation 15 

4.4.4 Conventions 15 

4.5 Test execution 15 

4.5.1 Parameter variations 15 

4.5.2 Execution requirements 15 

4.6 Pass criterion 16 

4.6.1 Unanticipated behaviour from the DUT 16 

5 Test cases 16 

5.1 HCI architecture 16 

5.1.1 Overview 16 

5.1.2 Hosts 16 

5.1.3 Gates 17 

5.1.3.1 Conformance requirements 17 

5.1.4 Pipes 17 

5.1.4.1 Conformance requirements 17 

5.1.5 Registries 17 

5.1.5.1 Conformance requirements 17 

5.2 HCP 18 

5.2.1 HCP packets 18 

5.2.1.1 Conformance requirements 18 

5.2.2 HCP message structure 18 

5.2.2.1 Conformance requirements 18 

5.2.3 Message fragmentation 19 

5.2.3.1 Conformance requirements 19 

5.3 Instructions 19 

5.3.1 Commands 19 

5.3.1.1 Overview 19 

5.3.1.1.1 Conformance requirements 19 

5.3.1.2 Generic commands 19 



£75/ 



Release 8 4 ETSI TS 1 02 695-3 V8.3.0 (201 2-1 2) 

5.3.1.2.1 ANY_SET_PARAMETER 19 

5.3.1.2.2 ANY_GET_PARAMETER 20 

5.3.1.2.3 ANY_OPEN_PIPE 21 

5.3.1.2.4 ANY_CLOSE_PIPE 22 

5.3.1.3 Administration commands 23 

5.3.1.3.1 ADM_CREATE_PIPE 23 

5.3.1.3.2 ADM_NOTIFY_PIPE_CREATED 23 

5.3.1.3.3 ADM_DELETE_PIPE 23 

5.3.1.3.4 ADM_NOTIFY_PIPE_DELETED 23 

5.3.1.3.5 ADM_CLEAR_ALL_PIPE 24 

5.3.1.3.6 ADM_NOTIFY_ALL_PIPE_CLEARED 24 

5.3.2 Responses 24 

5.3.2.1 Conformance requirements 24 

5.3.2.2 Test case 1: responses received out of order, previous commands sent by host 24 

5.3.2.2.1 Test execution 24 

5.3.2.2.2 Initial conditions 24 

5.3.2.2.3 Test procedure 25 

5.3.2.3 Test case 2: responses received out of order, previous commands sent by host controller 25 

5.3.2.3.1 Test execution 25 

5.3.2.3.2 Initial conditions 25 

5.3.2.3.3 Test procedure 25 

5.3.3 Events 25 

5.3.3.1 Conformance requirements 25 

5.4 GATES and subclauses 26 

5.4.1 GATES 26 

5.4.1.1 Conformance requirements 26 

5.4.2 Management gates 26 

5.4.2.1 Administration gates 26 

5.4.2.1.1 Host controller administration gate 26 

5.4.2.1.2 Host administration gate 26 

5.4.2.2 Link management gate 27 

5.4.2.2.1 Host controller link management gate 27 

5.4.2.2.2 Host link management gate 27 

5.4.2.3 Identity management gate 28 

5.4.2.3.1 Local registry 28 

5.4.2.3.2 Remote registry 29 

5.4.2.4 Loop back gate 30 

5.4.2.4.1 Conformance requirements 30 

5.4.3 Generic gates 30 

5.5 HCI procedures 30 

5.5.1 Pipe management 30 

5.5.1.1 Pipe creation 30 

5.5.1.1.1 Conformance requirements 30 

5.5.1.1.3 Test case 2: pipe creation from host simulator to another host, host simulator not in other 

host's WHITELIST 31 

5.5.1.1.4 Test case 3: pipe creation from host simulator to another host, other host rejects pipe creation 32 

5.5.1.1.5 Test case 4: valid pipe creation from host controller to host simulator 32 

5.5.1.1.6 Test case 5: pipe creation from host simulator to host controller, pipe not supported by host 
controller 33 

5.5.1.2 Pipe deletion 33 

5.5.1.2.1 Conformance requirements 33 

5.5.1.2.2 Test case 1: valid pipe deletion from host simulator to another host 33 

5.5.1.3 Clear all Pipes 34 

5.5.1.3.1 Conformance requirements 34 

5.5.1.3.2 Test case 1: clear all pipes from host controller - static pipes, dynamic pipes to host 34 

5.5.2 Registry access 35 

5.5.3 Host and Gate discovery 35 

5.5.4 Session initialization 35 

5.5.4.1 Conformance requirements 35 

5.5.5 Loop back testing 36 

5.5.5.1 Conformance requirements 36 

5.5.5.2 Test case 1: pipe creation 36 



£75/ 



Release 8 


5.5.5.2.1 


5.5.5.2.2 


5.5.5.2.3 


5.6 


5.6.1 


5.6.1.1 


5.6.2 


5.6.3 


5.6.3.1 


5.6.3.2 


5.6.3.2.1 


5.6.3.3 


5.6.3.3.1 


5.6.3.3.2 


5.6.3.3.3 


5.6.3.3.4 


5.6.3.4 


5.6.3.4.1 


5.6.3.4.2 


5.6.3.4.3 


5.6.3.4.4 


5.6.4 


5.6.4.1 


5.6.4.1.1 


5.6.4.2 


5.6.4.2.1 


5.6.4.3 


5.6.4.3.1 


5.6.4.4 


5.6.4.4.1 


5.6.4.5 


5.6.4.5.1 


5.6.4.6 


5.6.4.6.1 


5.7 


5.7.1 


5.7.1.1 


5.7.2 


5.7.2.1 


5.7.2.2 


5.7.2.2.1 


5.7.2.3 


5.7.2.3.1 


5.7.2.3.2 


5.7.2.4 


5.7.2.4.1 


5.7.2.4.2 


5.7.2.4.3 


5.7.2.5 


5.7.2.5.1 


5.7.3 


5.7.3.1 


5.7.3.2 


5.7.3.2.1 


5.7.3.3 


5.7.3.3.1 


5.7.3.4 


5.7.3.4.1 


5.7.3.4.2 


5.7.4 


5.7.4.1 


5.7.4.1.1 



5 ETSI TS 1 02 695-3 V8.3.0 (201 2-1 2) 

Test execution 36 

Initial conditions 36 

Test procedure 36 

Contactless card emulation 36 

Overview 36 

Conformance requirements 36 

Void 36 

Gates 37 

Void 37 

Identity management gate 37 

Conformance requirements 37 

Card RF gates 37 

Overview 37 

Commands 37 

Events and subclauses 37 

Registry and subclauses 38 

Card application gates 42 

Overview 42 

Commands 43 

Events and subclauses 43 

Registry 44 

Procedures 44 

Use of contactless card application 44 

Conformance requirements 44 

NonlSO/IEC 14443-4 type A 45 

Conformance requirements 45 

Type B' RF technology 45 

Conformance requirements 45 

Type F RF technology 45 

Conformance requirements 45 

Update RF technology settings 46 

Conformance requirements 46 

Identity check 46 

Conformance requirements 46 

Contactless reader 46 

Overview 46 

Conformance requirements 46 

Reader RF gates 46 

Overview 46 

Command 47 

WR_XCHG_DATA 47 

Registries 47 

Type A reader RF gate 47 

Type B reader RF gate 48 

Events and subclauses 48 

Events 48 

EVT_READER_REQUESTED 48 

EVT_END_OPERATION 48 

Responses 49 

Conformance requirements 49 

Reader application gates 49 

Overview 49 

Command 49 

Conformance requirements 49 

Registry 49 

Conformance requirements 49 

Events and subclauses 49 

Events 49 

EVT_TARGET_DISCOVERED 50 

Procedures 50 

Use of contactless reader application 50 

Conformance requirements 50 



£75/ 



Release 8 6 ETSI TS 1 02 695-3 V8.3.0 (201 2-1 2) 

5.8 Connectivity 50 

5.8.1 Overview 50 

5.8.2 Connectivity gate and subclauses 50 

5.8.2.1 Connectivity gate 50 

5.8.2.2 Commands 51 

5.8.2.2.1 PRO_HOST_REQUEST 51 

5.8.2.3 Events and subclauses 51 

5.8.2.3.1 Events 51 

5.8.2.3.2 EVT_CONNECTIVITY 51 

5.8.2.3.3 Void 51 

5.8.2.3.4 EVT_0PERAT10N_ENDED 51 

5.8.2.3.5 EVT_TRANSACT10N 51 

5.8.2.4 Registry 52 

5.8.2.4.1 Conformance requirements 52 

5.8.3 Connectivity application gate and subclauses 52 

5.8.3.1 Connectivity application gate 52 

5.8.3.1.1 Conformance requirements 52 

5.8.3.2 Commands 52 

5.8.3.2.1 Conformance requirements 52 

5.8.3.3 Events and subclauses 52 

5.8.3.3.1 Events 52 

5.8.3.3.2 EVT_STANDBY 52 

5.8.3.4 Registry 53 

5.8.3.4.1 Conformance requirements 53 

5.8.4 Procedures 53 

5.8.4.1 Use of connectivity gate 53 

Annex A (informative) : Bibliography 54 

Annex B (informative): Core specification version information 55 

Annex C(informative): Change history 56 

History 57 



£75/ 



Release 8 7 ETSI TS 1 02 695-3 V8.3.0 (201 2-1 2) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Smart Card Platform (SCP). 

The contents of the present document are subject to continuing work within TC SCP and may change following formal 
TC SCP approval. If TC SCP modifies the contents of the present document, it will then be republished by ETSI with 
an identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

early working draft; 

1 presented to TC SCP for information; 

2 presented to TC SCP for approval; 

3 or greater indicates TC SCP approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 

The present document is part 3 of a multi-part deliverable covering the Test specification for the Host Controller 
Interface (HCI), as identified below: 

Parti: "Terminal features"; 

Part 2: "UICC features"; 

Part 3: "Host Controller features". 



Introduction 



The present document defines test cases for the terminal relating to the Host Controller Interface (HCI) as specified in 
TS 102 622 [1]. 

The aim of the present document is to ensure interoperabiUty between the terminal and the UICC independently of the 
respective manufacturer, card issuer or operator. 
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1 Scope 

The present document covers additional test cases for the Host Controller to those specified in TS 102 695-1 [10]. 
The present document specifies the test cases for: 

• the HCI core as described in the first part of TS 102 622 [1]; 

• the contactless platform as described in the second part of TS 102 622 [1]. 

Test cases for the UICC and terminal relating to TS 102 622 [1] and test cases for the Single Wire Protocol (SWP) 
covering both terminal and UICC are out of scope of the present document. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

• In the case of a reference to a TC SCP document, a non specific reference implicitly refers to the latest version 
of that document in the same Release as the present document. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 102 622: "Smart Cards; UICC - Contactless Front-end (CLE) Interface; Host Controller 

Interface (HCI)". 

[2] ETSI TS 102 613: "Smart Cards; UICC - Contactless Front-end (CLE) Interface; Pait 1: Physical 

and data link layer characteristics". 

[3] ETSI TS 102 223: "Smart Cards; Card Apphcation Toolkit (CAT)". 

[4] ISO/lEC 18092: "Information technology - Telecommunications and information exchange 

between systems - Near Field Communication - Interface and Protocol (NFCIP-1)". 

[5] ISO/lEC 14443-2: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - 

Part 2: Radio frequency power and signal interface". 

[6] ISO/lEC 14443-3: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - 

Part 3: Initialization and anticollision". 

[7] ISO/lEC 14443-4: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - 

Part 4: Transmission Protocol". 

[8] ISO/lEC 7816-4: "Information technology - Identification cards - Integrated circuit(s) cards with 

contacts - Part 4: Interindustry commands for interchange". 

[9] ISO/IEC 9646-7: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 7: Implementation Conformance Statements". 

[10] ETSI TS 102 695-1: "Smart Cards; Test specification for the Host Controller Interface (HCI); 

Part 1: Terminal features". 
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2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

Not applicable. 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TS 102 622 [1] and the following apply: 

allowed error response code: response code which is not ANY_OK and which is allowed for the referenced command 
as specified in TS 102 622 [1] 

non-occurrence RQ: RQ which has been extracted from TS 102 622 [1], but which indicates a situation which should 
never occur 

NOTE: The consequence is that such RQs cannot be explicitly tested. 

user: any logical or physical entity which controls the test equipment in a way that it is able to trigger activities of the 
DUT 

3.2 Symbols 

For the purposes of the present document, the symbols given in TS 102 622 [1] and the following apply: 

PIPEO the static pipe connected to the link management gate of the device under test. 

PlPEl the static pipe connected to the administration gate of the device under test. 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in TS 102 622 [1] and the following apply: 

AC Alternating Current 

DUT Device under test 

FFS For further study 

HCUT Host controller Under Test 

HS Host Simulator 

ICRx Initial condition requirement (where x is a number) 

NOTE: As used in the applicability table; see clauses 4.2 and 4.5.2. 

NAA Network Access Application 

PCD Proximity Coupling Device 

PICC Proximity Card 

RFU Reserved for Future Use 

RO Read-Only 

RQ Conformance requirement 

RW Read-Write 

SDL Specification and Description Language 

SRx Static requirement (where x is a number) 

NOTE: As used in the applicability table; see clauses 4.2 and 4.5.2. 

TRx Trigger requirement (where x is a number) 

NOTE: As used in the applicability table; see clauses 4.2 and 4.5.2. 
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WO 



Write-Only 



3.4 Formats 

3.4.1 Format of the table of optional features 

The columns in table 4.1 have the following meaning. 



Column 


Meaning 


Option 


The optional feature supported or not by the DUT. 


Status 


See clause 3.4.3. 


Support 


The support columns shall be filled in by the supplier of the implementation. The following common 
notations, defined in ISO/IEC 9646-7 [9], are used for the support column in table 4.1 . 
Y or y supported by the implementation 
N or n not supported by the implementation 

N/A, n/a or - no answer required (allowed only if the status is N/A, directly or after evaluation of a 
conditional status) 


IVInemonic 


The mnemonic column contains mnemonic identifiers for each item. 



3.4.2 Format of the applicability table 

The applicability of every test in table 4.2 is formally expressed by the use of Boolean expression defined in the 
following clause. 

The columns in table 4.2 have the following meaning. 



Column 


Meaning 


Clause 


The "Clause" column identifies the clause containing the test case referenced in the "Test case number 
and description" column. 


Test case 
number and 
description 


The "Test case number and description" column gives a reference to the test case number (along with 
the corresponding description) detailed in the present document and required to validate the DUT. 


Release 


The "Release" column gives the Release applicable and onwards, for the corresponding test case. 


Execution 
requirements 


The usage of the "Execution requirements" column is described in clause 4.5.2. 


Rel-x Terminal 


For a given Release, the corresponding "Rel-x " column lists the tests required for a DUT to be declared 
compliant to this Release. 


Support 


The "Support" column is blank in the proforma, and shall be completed by the manufacturer in respect of 
each particular requirement to indicate the choices, which have been made in the implementation. 



3.4.3 Status and Notations 

The "Rel-x" columns show the status of the entries as follows: 

The following notations, defined in ISO/IEC 9646-7 [9], are used for the status column: 



M 
O 

N/A 

X 

O.i 



mandatory - the capability is required to be supported. 

optional - the capability may be supported or not. 

not applicable - in the given context, it is impossible to use the capability. 

prohibited (excluded) - there is a requirement not to use this capability in the given context. 

qualified optional - for mutually exclusive or selectable options from a set. "i" is an integer which 
identifies an unique group of related optional items and the logic of their selection which is 
defined immediately following the table. 
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Ci conditional - the requirement on the capability ("M", "O", "X" or "N/A") depends on the support 

of other optional or conditional items, "i" is an integer identifying an unique conditional status 
expression which is defined immediately following the table. For nested conditional expressions, 
the syntax "IF ... THEN (IF ... THEN ... ELSE...) ELSE ..." shall be used to avoid ambiguities. 

References to items 

For each possible item answer (answer in the support column) there exists a unique reference, used, for example, in the 
conditional expressions. It is defined as the table identifier, followed by a solidus character "/", followed by the item 
number in the table. If there is more than one support column in a table, the columns shall be discriminated by letters 
(a, b, etc.), respectively. 



EXAMPLE: 



4. 1/4 is the reference to the answer of item 4 in table 4. 1 . 



4 Test environment 

4.1 Table of optional features 

The device supplier shall state the support of possible options in table 4.L See clause 3.4 for the format of table 4.1. 

Table 4.1 : Options 



Item 


Option 


Status 


Support 


Mnemonic 


1 


Data link layer specified in TS 102 613 [2] is used 







102 613 


2 


ANY_OPEN_PIPE command transmission is 
implemented in the terminal 







0_OPEN_PIPE 


3 


ANY_CLOSE_PIPE command transmission is 
implemented in the terminal 







0_CLOSE_PIPE 


4 


ADIVI_CREATE_PIPE command transmission is 
implemented in the terminal 







0_CREATE_PIPE 


5 


ADM_NOTIFY_ALL_PIPE_CLEARED command 
transmission is implemented in the terminal, with the 
host controller as the requesting host 







0_NTF_PIPE_CL_HC 
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4.2 Applicability table 



Tables 4.2 specifies the applicability of each test case to the device under test. See clause 3.4 for the format of tables 4.2. 

Clause 4.5.2 should be referenced for usage of the execution requirements which are referenced in table 4.2 a) and described in table 4.2 c). 

Table 4.2 a): Applicability of tests 



Clause 


Test case number and description 


Release 


Execution 
requirements 


Rel-7 


Rel-8 


Support 


5.3.1.2.1.2 


Test case 1 : ANY SET PARAMETER reception - invalid structure 


Rel-7 




M 


M 




5.3.1.2.1.3 


Test case 2: ANY SET PARAIVIETER reception - RO registry parameter 


Rel-7 




M 


M 




5.3.1.2.2.2 


Test case 1 : ANY GET PARAMETER reception - invalid structure 


Rel-7 




M 


M 




5.3.1.2.2.3 


Test case 2: ANY GET PARAMETER reception - WO registry parameter 


Rel-7 


SRI 


M 


M 




5.3.1.2.3.2 


Test case 1 : ANY OPEN PIPE transmission 


Rel-7 


TR1 


G102 


CI 02 




5.3.1.2.4.2 


Test case 1 : ANY CLOSE PIPE transmission 


Rel-7 


TR2 


G103 


CI 03 




5.3.2.2 


Test case 1 : responses received out of order, previous command sent by host 


Rel-7 




M 


M 




5.3.2.3 


Test case 2: responses received out of order, previous command sent by host controller 


Rel-7 


TR1 


G102 


CI 02 




5.4.2.2.1.2 


Test case 1 : REG ERROR 


Rel-7 


IGR1 


M 


M 




5.4.2.2.2.2 


Test case 1 : REG ERROR 


Rel-7 


TR3 


M 


M 




5.4.2.3.1.2 


Test case 1 : registry parameters - optional registries 


Rel-7 












5.5.1.1.2 


Test case 1 : valid pipe creation from host simulator to another host 


Rel-7 


SR2 


M 


M 




5.5.1.1.3 


Test case 2: pipe creation from host simulator to another host, host simulator not in other host's WHITELIST 


Rel-7 


SR3 


M 


M 




5.5.1.1.4 


Test case 3: pipe creation from host simulator to another host, other host rejects pipe creation 


Rel-7 


SR4 


M 


M 




5.5.1.1.5 


Test case 4: valid pipe creation from host controller to host simulator 


Rel-7 


TR4 


CI 04 


CI 04 




5.5.1.1.6 


Test case 5: pipe creation from host simulator to host controller, pipe not supported by host controller 


Rel-7 


SR5 


M 


M 




5.5.1.2.2 


Test case 1 : valid pipe deletion from host simulator to another host 


Rel-7 


SR2 


M 


M 




5.5.1.3.2 


Test case 1 : clear all pipes from host controller - static pipes, dynamic pipes to host 


Rel-7 


TR5 


CI 05 


CI 05 




5.5.5.2 


Test case 1 : pipe creation 


Rel-7 




M 


M 




5.6.3.3.4.2.2 


Test case 1 : MODE parameter 






M 


M 




5.6.3.3.4.2.3 


Test case 2: DID REG - verify parameter 


Rel-7 




M 


M 




5.6.3.3.4.2.4 


Test case 3: FWI, SFGI 


Rel-7 




M 


M 




5.6.3.3.4.3.2 


MODE parameter 


Rel-7 




M 


M 





Table 4.2 b): Conditional items referenced by table 4.2 a) 



Conditional item 


Condition 


Description 


C101 


IF 4.1/1 THEN MELSEN/A 


102 613 


CI 02 


IF 4.1/2 THEN MELSEN/A 


OPEN PIPE 


CI 03 


IF 4.1/3 THEN MELSEN/A 


CLOSE PIPE 


CI 04 


IF 4.1/4 THEN MELSEN/A 


CREATE PIPE 


C105 


IF 4.1/5 THEN MELSEN/A 


NTF PIPE GL HG 
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Table 4.2 c): Execution requirements referenced by table 4.2 a) 



Execution 
requirement 



Description 



SR1 



A gate which contains at least one WO registry parameter. 



SR2 



Another host exists, with which the host simulator can communicate (i.e. host simulator is in the WHITELIST). 



SR3 



Another host exists, with which the host simulator cannot communicate (i.e. host simulator is not in the WHITELIST). 



SR4 



Another host exists, with which the host simulator can communicate 
GATES LIST of this host. 



(i.e. host simulator is in the WHITELIST). A valid Gid exists, which is not contained in the 



SR5 



A Gid exists for which the host controller does not support pipe creation. 



TR1 



Trigger the host controller to open PIPE_ID_I\/IAN. 



TR2 



Trigger the host controller to close PIPE_ID_MAN. 



TR3 



Trigger the host controller to write a value of REC_ERROR into the registry of the host simulator's link management gate in order to restart an error rate measure. 



TR4 



Trigger the host controller to send ADM_CREATE_PIPE to the host simulator. 



TR5 



Trigger the host controller to send ADM_NOTIFY_ALL_PIPE_CLEARED to the host simulator, with the host controller as the requesting host. 



IGR1 



The last value of REC_ERROR in the host's registry for PIPEO is not '0000' (TBC). 



NOTE: Clause 4.5.2 should be referenced for the meaning and usage of the execution requirements which are described In table 4.2 c). 
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4.3 Information to be provided by the device supplier 

The device supplier shall provide the information indicated in table 4.3. 

Table 4.3: Default configuration 



Item 


Description 


Presence/Value 


Status 


Mnemonic 


1 


Indication of presence of VERSION SW, and value if supported. 




M 


V VERSION SW 


2 


Indication of presence of VERSION HARD, and value if supported. 




M 


V VERSION HARD 


3 


Indication of presence of VENDOR NAIVIE, and value if supported. 




M 


V VENDOR NAME 


4 


Indication of presence of IVIODEL ID, and value if supported. 




M 


V MODEL ID 


5 


Indication of presence of HCI VERSION, and value if supported. 




M 


V HCI VERSION 


6 


Value of GATES LIST 




M 


V GATES LIST 


7 


Value of MAX PIPE 




M 


V MAX PIPE 


8 


Value of HOST LIST 




M 


V HOST LIST 


NOTE: Conditional values shall be provided if the corresponding option is supported in the table 4.1 . 



4.4 Test equipment 



The test equipment shall provide a host simulator which is connected to the DUT during test procedure execution, 
unless otherwise specified. 

With respect to the DUT, the host simulator shall act as a valid host according to TS 102 622 [1] unless otherwise 
specified. In particular, the host simulator shall ensure that the value GATES_LIST is valid, according to the particular 
requirements of the test case being executed. 

With respect to the DUT, the host simulator shall comprise a valid host according to the specific DUT. The details are 
out of the scope of the present document. 

For some test cases, usage of a PCD is required. The detailed requirements are specified in the individual test cases. 

The test equipment shall ensure that a matching SYNC_ID is used during test case execution, unless otherwise 
specified. 

Some terminals might require the presence of an NAA (e.g. (U)SIM), which shall be provided by the test equipment. 

Note: the implementation of the terminal may imply certain activities or settings on the HCI layer. This should be taken 
into account when testing the HCI interface (e.g. PIPE state should be checked, activity after initialization, already open 
pipes, etc.). 

With respect to the DUT, the host simulator shall act as a valid host according to TS 102 622 [1] unless otherwise 
specified. In particular, the host simulator shall ensure before running a test case that all static pipes are closed, all 
dynamic pipes are deleted and the registry values are set to their defaults by running the sequence in table 4.4. 

Table 4.4: HCI test case initialization sequence 



Step 


Direction 


Description 


a1 


HS^ HCUT 


Send ANY OPEN PIPEonPIPEL 


a2 


HCUT^ HS 


Send ANY OK. 


aS 


HS-> HCUT 


Send ADM CLEAR ALL PIPE on PIPE1 with parameter. ('FF FF'). 


a4 


HCUT^ HS 


Send ANY OK. 



Before the execution of the RF technology test cases, RF gate parameters has to be modified properly to run the test. 

4.4.1 Measurement / setting uncertainties 

Void. 
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4.4.2 Default conditions for DUT operation 

Unless otherwise specified, the test equipment shall apply the default conditions described in the following subclauses 
during test procedure execution. 

4.4.2.1 General 

The test equipment shall attempt to ensure that the identity check mechanism of the lower layer passes (see 
TS 102 622 [1], clause 8.4). 

If the test procedure indicates that the host simulator is to send AN Y_OK in response to an ANY_OPEN_PIPE 
command, the parameter shall contain the number of pipes already open on the gate before the execution of the 
command. 

4.4.2.2 Status of UICC interfaces 

Void. 

4.4.3 Minimum/maximum conditions for DUT operation 

Void. 

4.4.4 Conventions 

Unless otherwise specified, ADM_CREATE_PIPE is sent by the test equipment with source Hid = Hid of host simulator 
and destination Hid = Hid of host controller. 

If the pipe for a response is not explicitly specified, then the pipe for the response is required to be the pipe on which the 
preceding command was sent. 

4.5 Test execution 

4.5.1 Parameter variations 

Unless otherwise specified, all test cases shall be carried out in full power mode only, and for the parameter variations 
specified individually for each test case. 

4.5.2 Execution requirements 

Table 4.2, Applicability of tests, specifies "execution requirements" for several test cases. For these test cases, it has not 
been possible to specify the corresponding test procedure in such a way that it can be guaranteed that the test procedure 
can be executed against every possible DUT. 

Some sample scenarios of test requirements are listed below: 

• The test case requires certain state to be present on the DUT in order to test a particular feature, but there is no 
mandatory requirement in the core specification (TS 102 622 [1]) for this state to be present. 

• The test case requires the DUT to perform a particular operation in order to test that feature, but the core 
specification (TS 102 622 [1]) does not provide a standardized mechanism to trigger that operation to be 
executed by the DUT. 

The test requirements have been split into various categories, as indicated by table 4.2 c): 

• Static requirements (SRx): information about, for example, particular gates or registry parameters which can 
be used in the test procedure execution. 

• Trigger requirements (TRx): mechanisms for triggering the DUT to perform certain operations. 
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• Initial condition requirements (ICRx): information about how to establish initial condition states. 

The DUT supplier should make every effort to provide appropriate information or mechanisms to allow these execution 
requirements to be satisfied for the DUT. 

It is recognised that this might not always be possible. For example, if the configuration of the DUT does not allow for 
the required state to be present; or if it is not possible to provide a particular trigger mechanism for the DUT. In these 
cases, it is acceptable that the test case is not carried out. However, it should be recognised that the consequence is that 
the particular feature will not be tested. 

4.6 Pass criterion 

A test shall only be considered as successful, if the test procedure was carried out successfully under all parameter 
variations with the DUT respecting all conformance requirements referenced in the test procedure. This is subject to the 
additional qualifications described in clause 4.6.1. 

NOTE: Within the test procedures, the RQs are referenced in the step where they are observable. In some cases, 
this is different from the step where they occur with respect to the DUT. 

4.6.1 Unanticipated beinaviour from tine DUT 

In the specification of the test procedures, every attempt has been made to ensure that the interface between the 
simulator and the DUT is in a known state before and during test procedure execution. However, as the DUT is an 
autonomous device, it is not possible to fully guarantee this. 

If the DUT unexpectedly closes or deletes a pipe which is intended to be used during a subsequent part of the test 
procedure, this should not be considered as a failure of the DUT, even though the test procedure cannot be completed 
successfully. Instead, the test procedure should be executed again to attempt to execute the test procedure to 
completion. If the unexpected behaviour occurs again, further effort should be applied by the tester to attempt to ensure 
that the unexpected behaviour does not occur. 



5 Test cases 

5.1 HCI arclnitecture 

5.1.1 Overview 

Reference: TS 102 622 [1], clause 4.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.1.2 Hosts 

Reference: TS 102 622 [1], clause 4.2. 



RQ4.1 The host controller shall not use host identifiers which are RFU. 



RQ4.2 [The host controller shall reject received host identifiers which are RFU. 



NOTE 1 : RQ4.1 is a non-occurrence RQ. 

NOTE 2: Development of test cases for RQ4.2 is FFS. 
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5.1.3 Gates 

5.1.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 4.3. 



RQ4.3 


The host controller shall have one administration gate. 


RQ4.4 


The host controller shall have one link management gate. 


RQ4.5 


The host controller shall have one identity management gate. 


RQ4.6 


The host controller shall have one loop back gate. 


RQ4.7 


The host controller shall not use gate identifiers which are RFU. 


RQ4.8 


Void. 


RQ4.9 


The host controller shall not use gate identifiers which are host specific but not yet allocated in 
TS 102 622 [1]. 


RQ4.10 


Void. 


NOTE 1 : RQ4.7 and RQ4.9 are not tested, as they are non-occurrence RQs. 



5.1.4 Pipes 



5.1.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 4.4. 



RQ4.11 



The host controller shall not attempt to delete a static pipe. 



RQ4.12 



The host controller shall reject any attempts to delete a static pipe. 



RQ4.13 



The state of a pipe 
again. 



i.e. open or closed) shall remain persistent if the hosts are powered down and up 



RQ4.14 



The state of a dynamic pipe after creation shall be closed. 



RQ4.15 



The initial state of a static pipe shall be closed. 



RQ4.16 



The host controller shall not use pipe identifiers which are RFU. 



RQ4.17 



The state of a pipe shall remain persistent if a host is temporarily removed from the host network and 
was not replaced by a different device in the meantime. 



RQ4.18 



For dynamic pipes, pipe identifiers are dynamically allocated by the host controller. 



RQ4.19 



All pipe identifiers allocated by the host controller for dynamic pipes shall be in the range '02' to '6F'. 
Dynamic pipe identifiers shall be unique in the host network. 



RQ4.20 



NOTE 1 
NOTE 2 
NOTES 

NOTE 4: 



RQ4.11 and RQ4.16 are not tested, as they are non-occurrence RQs. 

RQ4.15 is not tested, as it is not clear when the initial state of the static pipe applies. 

RQ4.18 is covered in clause 8.1.1 of TS 102 622 [1], covered by clause 5.5.1.1 of the present document. 

This RQ is therefore not tested within this clause, as it is effectively tested in clause 5.5.1 .1 . 

RQ4.19 and RQ4.20 are tested implicitly in different test cases in this test specification. 



Reference: TS 102 622 [1], clauses 7.1.1.1. 



|R07.2 [The registry of the host controller administration gate shall be persistent. 



Reference: TS 102 622 [1], clauses 8.1.1, 6.1.3.1 and 6.1.3.2. 



R08.3 



The host controller assigns an unused pipe identifier. 



RO6.30 



When the pipe was successfully created, the host controller shall send the response ANY_OK in 

response to the ADIVI_CREATE_PIPE command, with parameters as specified in TS 102 622 [1]. 

When a pipe is created towards the host controller then only steps 1 and 4 in figure 6 of TS 102 622 [1] 
are needed. 



R08.7 



5.1.5 Registries 



5.1.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 4.5. 
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For all gates defined in TS 102 622 [1], parameter identifiers in the range of '00' to 'EF' are reserved for 
use in TS 102 622 [1], 



RQ4.21 



RQ4.22 



A new instance of the registry is created for every pipe that connects to the gate. 



RQ4.23 



Upon pipe creation all registry parameters with access rights Read-write (RW) or Write-only (WO) shall 
be set to their default values. 



RQ4.24 



Upon pipe creation all read-only (RO) parameters shall be set by the entity managing the registry to an 
appropriate value which may differ from the default values. 



RQ4.25 



When a pipe is deleted its registry instance is also deleted. 



RQ4.26 



Registry parameters which are in the range of '00' to 'EF' but which are not allocated in TS 102 622 [1] 
shall not be present in the registry. 



NOTE 1 : As the specification of registry parameters is specific to each individual registry, R04.21 , RQ4.23 and 
R04.24 are not tested in this clause, but are tested in other clauses of the present document for each 
individual registry. 

NOTE 2: RQ4.22 is not currently tested as TS 1 02 622 [1 ] does not specify any gates with the required properties 
to exercise this functionality. 

NOTE 3: Development of test cases for RQ4.26 is FFS. 



5.2 



HCP 



5.2.1 HCP packets 



5.2.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 5.1. 



R05.1 The host controller shall use the correct structure for transmitted HCP packets. 



R05.2 



The host controller shall recognise correctly structured received HCP packets. 



R05.3 



When receiving a packet, the host controller as destination host forwards the packet to the destination 
gate. 



R05.4 



When it receives a packet from a host, the host controller uses the value of P|d to forward a packet to the 
destination host. 



R05.5 



When it receives a packet from a host, the host controller shall verify that the pipe identifier is used by a 
host involved in the creation of the pipe. 



NOTE 1 : RQ5.1 and R05.2 are implicitly tested by the testing of higher layers in other clauses of the present 

document. 
NOTE 2: RQ5.3 is internal to the host controller and is not tested in this clause. It will be implicitly tested in many 

other test cases within the present document. 
NOTE 3: RQ5.4 and R05.5 are tested in clause 5.5.1.1.2 of the present document. 



5.2.2 HCP message structure 



5.2.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 5.2. 



R05.6 The host controller shall use the correct structure for transmitted HCP messages. 



R05.7 



Type value 3 shall not be used. 



R05.8 



The host controller shall recognise correctly structured received HCP messages. 



R05.9 



A gate shall only accept a command or an event on a pipe when the state of that pipe is open unless 
otherwise stated. 



RQ5.10 



A gate shall not send a command or event on a pipe when it is waiting for a response to a previous 
command on that pipe unless otherwise stated. 



NOTE 1 : RQ5.6 and R05.8 are implicitly tested by the testing of higher layers in other clauses of the present 

document. 
NOTE 2: RQ5.7 and RO5.10 are not tested, as they are non-occurrence ROs. 
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5.2.3 Message fragmentation 
5.2.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 5.3. 



RQ5.11 



Message fragmentation shall be used when the size of the message is larger than supported by the 
underlying data link layer. 



RQ5.12 



IVIessages shall be fragmented according to the rules specified in TS 102 622 [1]. 



RQ5.13 



The destination gate is responsible for rebuilding the message from the fragmented messages. 



RQ5.14 



If a reset of the underlying data link layer occurs, fragments of a partially received message shall be 
discarded and a partially sent message shall be re-sent from the beginning. 



NOTE: Development of test cases for RQ5. 11, RQ5.12, RQ5.13and RQ5.14isFFS. 



5.3 



Instructions 



5.3.1 Commands 



5.3.1.1 



Overview 



5.3.1 .1 .1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.1. 



RQ6.1 For all gates, the host controller shall not use RFU instruction values ('05' to 'OF') in commands. 



RQ6.2 



For administration gates, the host controller shall not use RFU instruction values ('16' to '3F') in 
commands. 



RQ6.3 



For gates defined in TS 1 02 622 [1 ], the host controller shall not use instruction values between '1 0' and 
'3F' which are not allocated in TS 102 622 [1]. 



NOTE: RQ6.1 , RQ6.2 and RQ6.3 are not tested, as they are non-occurrence RQs. 



5.3.1.2 



Generic commands 



5.3.1.2.1 



ANY SET PARAMETER 



5.3.1 .2.1 .1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.2.1. 



RQ6.4 


The host controller shall reject an incorrectly formatted ANY_SET_PARAMETER command with an 
allowed error response code. 


R06.5 


The host controller shall reject an ANY_SET_PARAIVIETER command if the access right for the 
parameter does not allowed writing (i.e. is not RW or WO). 


R06.6 


The host controller shall not send an ANY_SET_PARAIVIETER command if the access right for the 
parameter does not allow writing (i.e. is not RW or WO). 


RQ6.7 


When the host controller receives a valid ANY_SET_PARAIVIETER command, it shall write the 
parameter value into the registry and respond with ANY OK without any parameters. 


RQ6.8 


Whenever the host controller sends an ANY_SET_PARAMETER command, it shall do so correctly: 

• It shall only be sent to a gate which supports the command. 

• It shall always have at least one byte in the command parameters. 

• The parameter identifier shall match one of those defined for the specific gate. 

• The parameter value shall be a valid value as defined for the specific gate. 


NOTE 1 : RQ6.6 is not tested, as it is a non-occurrence RQ. 

NOTE 2: RQ6.7 and R06.8 are not tested in this clause, as they are effectively tested in other clauses of the 
present document for each individual registry parameter. 
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5.3.1 .2.1 .2 Test case 1 : ANY_SET_PARAMETER reception - invalid structure 

5.3.1.2.1.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.3.1.2.1.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is open. 

5.3.1.2.1.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send ANY SET PARAMETER with no parameters on PIPE1 . 




2 


HCUT^ HS 


Send response containing an allowed error response code for the command. 


RQ6.4 



5.3.1 .2.1 .3 Test case 2: ANY_SET_PARAMETER reception - RO registry parameter 

5.3.1.2.1.3.1 Test execution 

There are no test case-specific parameters for this test case. 

5.3.1.2.1.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host controller's identity management gate, and is open. 

5.3.1.2.1.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS ^ HCUT 


Send ANY_SET_PARAMETER(GATES_LIST) on PIPE_ID_MAN, where the 
parameter value is equal to the existing value of GATES_LIST in the host 
controller's registry. 




2 


HCUT-^ HS 


Send response containing an allowed error response code for the command. 


RQ6.5 



5.3.1.2.2 



ANY GET PARAMETER 



5.3.1.2.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.2.2. 



RQ6.9 



The host controller shall reject an incorrectly formatted ANY_GET_PARAMETER command with an 
allowed error response code. 



RQ6.10 



The host controller shall reject an ANY_GET_PARAMETER command if the access right for the 
parameter does not allowed reading (i.e. is not RW or RO). 



RQ6.11 



The host controller shall not send an ANY_GET_PARAMETER command if the access right for the 
parameter does not allowed reading (i.e. is not RW or RO). 



RQ6.12 



When the host controller receives a valid ANY_GET_PARAMETER command, it shall respond with 
ANY_OK with the value of the parameter. 



RQ6.13 



Whenever the host controller sends an ANY_GET_PARAMETER command, it shall do so correctly: 

• It shall only be sent to a gate which supports the command. 

• It shall always have exactly one byte in the command parameters. 

» The parameter identifier shall match one of those defined for the specific gate. 



NOTE 1 : RQ6.1 1 is not tested, as it is a non-occurrence RO. 

NOTE 2: RQ6.12 and RQ6.13 are not tested, as they are effectively tested in other clauses of the present 

document for each individual registry parameter. 
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5.3.1 .2.2.2 Test case 1 : ANY_GET_PARAMETER reception - invalid structure 

5.3.1.2.2.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.3.1.2.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host controller's identity management gate, and is open. 

5.3.1 .2.2.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send ANY GET PARAMETER with no parameters on PIPE ID MAN. 




2 


HCUT^ HS 


Send response containing an allowed error response code for the command. 


RQ6.9 


3 


HS^ HCUT 


Send ANY_GET_PARAMETER containing parameters of length 2, with each 
byte containing the value of the GATES LIST identifier, on PIPE ID MAN. 




4 


HCUT ^ HS 


Send response containing an allowed error response code for the command. 


RQ6.9 



5.3.1.2.2.3 



5.3.1.2.2.3.1 



Test case 2: ANY_GET_PARAMETER reception - WO registry parameter 
Test execution 



Assignment of terms to entities referenced in SRI : Gid of gate = GATE_X, registry parameter identifier : 
REG_PARAM. 

There are no test case-specific parameters for this test case. 

5.3.1.2.2.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_X) has been created to the gate with Gm = GATE_X, and is open. 

5.3.1 .2.2.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send ANY GET PARAMETER(REG PARAM) on PIPE X. 




2 


HCUT^ HS 


Send response containing an allowed error response code for the command. 


RQ6.10 



5.3.1.2.3 



ANY OPEN PIPE 



5.3.1.2.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.2.3. 



RQ6.14 The host controller shall reject an incorrectly formatted ANY_OPEN_PIPE command. 



RQ6.15 



When the host controller receives a valid ANY_OPEN_PIPE command on a closed pipe, it shall open the 
pipe and return ANY_OK without any parameter. 



RQ6.16 



When the host controller sends an ANYOPENPIPE command, it shall contain no command 
parameters. 



RQ6.17 



When the host controller receives ANYOK in response to an ANYOPENPIPE command, it shall open 
the pipe. 



NOTE: In TS 102 622 [1], it is not specified whether ANY_OPEN_PIPE is valid over a pipe which is already 
open. This is therefore not listed as a conformance requirement. 
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5.3.1.2.3.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.3.1.2.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host controller's identity management gate, and is open. 

5.3.1 .2.3.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send ANY CLOSE PIPE on PIPE ID MAN. 




2 


HCUT^ HS 


Send ANY OK. 




3 


User ^ HCUT 


Trigger the host controller to open PIPE ID MAN. 




4 


HCUT^ HS 


Send ANY OPEN PIPE on PIPE ID MAN. 


RQ6.16 


5 


HS^ HCUT 


Send ANY OK with valid response parameter. 




6 


HS^ HCUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




7 


HCUT^ HS 


Send ANY_OK (parameters are not checked). 


RQ6.17 



5.3.1.2.4 



ANY CLOSE PIPE 



5.3.1 .2.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.2.4. 



RQ6.18 


The host controller shall reject an incorrectly formatted ANY CLOSE PIPE command. 


RQ6.19 


When the host controller receives a valid ANY_CLOSE_PIPE on an open pipe, it shall close the pipe and 
respond with ANY OK and no parameters. 


RQ6.20 


When the host controller sends an ANYCLOSEPIPE command, it shall contain no command 
parameters. 


RQ6.21 


When the host controller receives ANY_OK in response to an ANY_CLOSE_PIPE command, it shall 
close the pipe. 



5.3.1.2.4.2 



Test case 1 : ANY CLOSE PIPE transmission 



5.3.1.2.4.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.3.1.2.4.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host controller's identity management gate, and is open. 

5.3.1 .2.4.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ HCUT 


Trigger the host controller to close PIPE ID MAN. 




2 


HCUT^ HS 


Send ANY CLOSE PIPE on PIPE ID MAN. 


RQ6.20 


3 


HS^ HCUT 


Send ANY OK. 




4 


HS ^ HCUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




5 


HCUT^ HS 


Send response containing an allowed error response code for the command. 


RQ6.21 
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5.3.1.3 



Administration commands 



5.3.1.3.1 



ADM CREATE PIPE 



5.3.1 .3.1 .1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.1. 



RQ6.22 



When the host controller receives an ADM_CREATE_PIPE command, it shall use the WHITELIST 
defined by the destination host in order to verify that the source host is authorized to create a pipe. 



RQ6.23 



When the pipe was successfully created, the host controller shall send the response ANY_OK in 
response to the ADM_CREATE_PIPE command, with parameters as specified in TS 102 622 [1], 



RQ6.42 



When receiving ADM_CREATE_PIPE, the host controller shall accept any gate identifier being used as 
source gate. 



NOTE 1 : All conformance requirements for the referenced clause are included in clauses 5.5.1 .1 and 5.1 .4.3 of the 

present document. 
NOTE 2: Development of test cases for RQ6.42 is FFS. 



5.3.1.3.2 



ADM NOTIFY PIPE CREATED 



5.3.1.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.2. 



R06.24 



When the host controller sends an ADM_NOTIFY_PIPE_CREATED command, the command 
parameters shall be 5 bytes long. 



R06.25 



When the host controller sends an ADM_NOTIFY_PIPE_CREATED command as a result of an 
ADM_CREATE_PIPE command being received from a host, the source Hid in the command 
parameters shall be the Hip of that host. 



NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1 .1 of the present 
document. 



5.3.1.3.3 



ADM DELETE PIPE 



5.3.1.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.3. 



RQ6.26 The host that requested the deletion of the pipe can only be the source host or destination host. 



RQ6.27 



When the pipe is successfully deleted, the host controller shall send the response ANYOK without 
parameters. 



NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1 .2 of the present 
document. 



5.3.1.3.4 



ADM NOTIFY PIPE DELETED 



5.3.1.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.4. 



RQ6.28 



When the host controller sends an ADM_NOTIFY_PIPE_DELETED command, the command 
parameters shall be 1 byte long. 



NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1 .2 of the present 
document. 
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5.3.1.3.5 



ADM CLEAR ALL PIPE 



5.3.1.3.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.5. 



RQ6.29 



When the host controller receives a valid ADM_CLEAR_ALL_PIPE command and the data link layer 
specified in TS 102 613 [2] is used, it shall interpret the two bytes in the command parameters as the 
identity reference data, and shall use the identity reference data to initialize the reference data used by 
the host controller to check the UICC host identity. 



RQ6.30 



When the host controller receives a valid ADM_CLEAR_ALL_PIPE command, it shall delete all the 
dynamic pipes connected to the requesting host, close all static pipes connected to the requesting host 
and set all registry values related to static pipes connected to the requesting host to their default values. 



RQ6.31 



When ADMCLEARALLPIPE is successful the host controller shall respond with an ANYOK without 
parameters. 



NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1 .3 of the present 
document. 



5.3.1.3.6 



ADM NOTIFY ALL PIPE CLEARED 



5.3.1.3.6.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.6. 



RQ6.32 



When the host controller receives a valid ADM_CLEAR_ALL_PIPE command from a requesting host, it 
shall send ADM_NOTIFY_ALL_PIPE_CLEARED to every host with at least one pipe to the requesting 
host. 



RQ6.33 



When the host controller sends an ADM_NOTIFY_ALL_PIPE_CLEARED command with the host 
controller as the requesting host, it shall delete all dynamic pipes between the host controller and the host 
and shall close all static pipes between the host and the host controller. 



RQ6.34 



When the host controller sends an ADM_NOTIFY_ALL_PIPE_CLEARED command, the command 
parameters shall be one byte long and shall contain the Hip of the requesting host. 



NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1 .3 of the present 
document. 



5.3.2 Responses 



5.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.2. 



R06.35 A response shall be sent to all commands received even to those unknown to the receiving gate. 



R06.36 



Responses received out of order (i.e. if no command was sent previously) shall be discarded. 



R06.37 



For a received command which is defined in table 16 in TS 102 622 [1], the host controller shall only 
return a response code which is specified for that command in table 16 in TS 102 622 [1]. 



NOTE: Development of test cases for RQ6.37 is FFS. 



5.3.2.2 Test case 1 : responses received out of order, previous commands sent by 

host 

5.3.2.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.3.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host controller's identity management gate, and is open. 
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5.3.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS ^ HCUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




2 


HCUT^ HS 


Send response with ANY OK and value of GATES LIST on PIPE ID MAN. 




3 


HS^ HCUT 


Send response with ANY OK and no parameters on PIPE ID MAN. 




4 


HCUT 


No message on PIPE ID MAN. 


R06.36 


5 


HS^ HCUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




6 


HCUT^ HS 


Send response with ANYOK and same value of GATES_LIST as in step 2. 


RQ6.36 



5.3.2.3 Test case 2: responses received out of order, previous commands sent by 

host controller 

5.3.2.3.1 Test execution 

There are no test case-specific parameters for this test case. 

5.3.2.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host controller's identity management gate, and is open. 



5.3.2.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS ^ HCUT 


Send ANY CLOSE PIPE on PIPE ID MAN. 




2 


HCUT-^ HS 


Send ANY OK. 




3 


User ^ HCUT 


Trigger the host controller to open PIPE ID MAN. 




4 


HCUT^ HS 


Send ANY OPEN PIPE on PIPE ID MAN. 




5 


HS^ HCUT 


Send ANY OK with valid response parameter on PIPE ID MAN. 




6 


HS ^ HCUT 


Send ANY E NOKonPIPE ID MAN. 




7 


HCUT 


No message on PIPE ID MAN. 


R06.36 


8 


HS ^ HCUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




9 


HCUT-^ HS 


Send response with ANY OK and value of GATES LIST on PIPE ID MAN. 


R06.36 



5.3.3 Events 



5.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.3. 



RQ6.38 Unknown events received shall be discarded. 



RQ6.39 



EVT_HOT_PLUG shall be sent by the host controller to any other connected host to notify the 
connection or disconnection of a host to the host controller. 



RQ6.40 



When the host controller send EVT_HOT_PLUG, it shall contain no parameters. 



RQ6.41 



For gates defined in TS 1 02 622 [1 ] 
inTS102 622[1]. 



the host controller shall not use event values which are not allocated 



NOTE 1 : R06.41 is not tested, as it is a non-occurrence RO. 
NOTE 2: Development of test cases for RQ6.39 and RO6.40 is FFS. 
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5.4 



GATES and subclauses 



5.4.1 GATES 



5.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7. 



RQ7.1 [Gates shall support the commands and events specified for them in tables 18 and 19 of TS 102 622 [1], 



NOTE 1 : RQ1 is not tested in this clause, as it is effectively tested in other clauses of the present document. 
NOTE 2: ANY_GET_PARAMETER and ANY_SET_PARAMETER are not tested in this clause, as they are tested 

in the specific clauses for each gate for testing registry parameters. 
NOTE 3: ADI\/I_CREATE_PIPE, ADM_DELETE_PIPE and ADM_GLEAR_ALL_PIPE are not tested for the host 

controller administration gate, as they are tested in the specific clauses for each command. 
NOTE 4: EVT_POST_DATA is not tested for the loop back gate, as it is tested in the clause 5.5.5. 
NOTE 5: EVT_HCI_END_OF_OPERATION is not tested for the host controller link management gate, as the 
reaction of the host controller is not specified in TS 102 622 [1]. 



5.4.2 Management gates 



5.4.2.1 



Administration gates 



5.4.2.1.1 



Host controller administration gate 



5.4.2.1 .1 .1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.1.1 and 4.5. 



RQ4.26 



Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not defined in 
TS 102 622 [1] shall not be present in the registry. 



RQ7.2 



The registry of the host controller administration gate shall be persistent. 



RQ7.3 



The host controller shall use a default value for SESSION IDENTITY of 'FFFFFFFFFFFFFFFF'. 



RQ7.4 



The host controller shall apply the access condition of RW to SESSIONJDENTITY. 



RQ7.5 



The host controller shall only accept values of SESSIONJDENTITY of length 8 bytes. 



RQ7.6 



The host controller shall use a default value for MAX PIPE of between '10' and '7D' inclusive. 



RQ7.7 



The host controller shall apply the access condition of RO to MAX_PIPE. 



RQ7.8 



The host controller shall allow MAX_PIPE created dynamic pipes for the host. 



RQ7.9 



The host controller shall use a default value for WHITELIST of an empty array. 



RQ7.10 



The host controller shall apply the access condition of RW to WHITELIST. 



R07.11 



The host controller shall use a default value for HOST_LIST containing the list of the hosts that are accessible 
from this host controller including the host controller itself, as a list of host identifiers. 



R07.12 



The host controller shall apply the access condition of RO to HOST_LIST. 



R07.13 



The H0ST_LIST shall contain the list of the hosts that are accessible from this host controller including the host 
controller itself. 



RQ7.14 



The host controller shall reject create pipe requests if the source host is not listed in the WHITELIST of the 
destination host. 



NOTE 1 : Development of test cases for RQ4.26 and RQ7.8 is FFS. 

NOTE 2: R07.13 is only tested in the context of R07.1 1 (i.e. default value). 

NOTE 3: RQ7.14 is also covered in clause 8.1.1 of TS 102 622 [1], covered by clause 5.5.1.1 of the present document. 

This RQ is therefore not tested within this clause, as it is effectively tested in clause 5.5.1 .1 . 
NOTE 4: RQ7.2 is tested in clause 5.1 .4.3 of the present document. 



5.4.2.1.2 



Host administration gate 



5.4.2.1.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7.1.1.2. 
There are no conformance requirements for the terminal for the referenced clause. 



£75/ 



Release 8 



27 



ETSI TS 102 695-3 V8.3.0 (2012-12) 



5.4.2.2 Link management gate 

5.4.2.2.1 Host controller link management gate 

5.4.2.2.1.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.2.1 and 4.5. 



RQ4.26 



Registry parameters whicli are in tlie range reserved for usage by TS 1 02 622 [1 ] but which are not defined in 
TS 102 622 [1] shall not be present in the registry. 



RQ7.15 



The host controller shall use a default value for REG ERROR of '0000'. 



RQ7.16 



The host controller shall apply the access condition of RW to REC_ERROR. 



RQ7.17 [The host controller shall only accept values of REC_ERROR of length 2 bytes. 



NOTE: Development of test cases for RQ4.26 is FFS. 



5.4.2.2.1.2 



Test case 1 : REC ERROR 



5.4.2.2.1.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.4.2.2.1.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is currently open. 



5.4.2.2.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send ADM CLEAR ALL PIPE on PIPEl. 




2 


HCUT^ HS 


Send ANY OK (parameters are not checked). 




3 


HS^ HCUT 


Send ANY OPEN PIPE on PIPEO. 




4 


HCUT ^ HS 


Send ANY OK 




5 


HS^ HCUT 


Send ANY GET PARAMETER(REC ERROR) on PIPEO. 




6 


HCUT^ HS 


Send ANY_OK with parameter value '0000' (see note). 


R07.15, 
RQ7.16 


7 


HS^ HCUT 


Send ANY SET PARAMETER(REC ERROR, '0000') on PIPEO. 




8 


HCUT ^ HS 


Send ANY OK. 


RQ7.16 


9 


HS^ HCUT 


Send ANY SET PARAMETER(REC ERROR, '000000') on PIPEO. 




10 


HCUT-^ HS 


Send response containing an allowed error response code for the command. 


RQ7.17 


NOTE: This assumes that the HCI session initialization procedure has not resulted in any errors at the data 
link layer which would result in the incrementing of REC ERROR. 



5.4.2.2.2 



Host link management gate 



5.4.2.2.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7.1.2.2. 



|R07.18 [The host controller shall only set values of REC_ERROR with length 2 bytes. 



5.4.2.2.2.2 



Test case 1 : REC ERROR 



5.4.2.2.2.2.1 Test execution 

There are no test case-specific parameters for this test case. 
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5.4.2.2.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEO is open. 

5.4.2.2.2.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ HCUT 


Trigger the host controller to write a value of REC_ERROR into the registry 
of the host simulator's link management gate in order to restart an error rate 
measure. 




2 


HCUT^ HS 


Send ANY SET PARAMETER(REC ERROR) on PIPEO. 


R07.18 


3 


HS^ HCUT 


Send ANY OK. 





5.4.2.3 Identity management gate 

5.4.2.3.1 Local registry 



5.4.2.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.3 and 4.5. 

NOTE: This clause covers the conformance requirements contained within TS 102 622 [1], clause 7.1.3 for the 
local registry. The requirements for the remote registry are contained in clause 5.4.2.3.2. 



RQ4.26 



Registry parameters which are in the range of '00' to 'EF' but which are not allocated in TS 102 622 [1] 
shall not be present in the registry. 



The registry of the identity management gate shall be persistent. 



RQ7.19 



RQ7.20 



This gate shall be provided by all hosts and the host controller. 



RQ7.21 



If present in the host controller, the host controller shall use a value for VERSION_SW of length 
3 bytes. 



RQ7.22 



If present in the host controller, the host controller shall apply the access condition of RO to 
VERSION SW. 



RQ7.23 



If present in the host controller, the host controller shall use a value for VERSION_HARD of length 
3 bytes. 



RQ7.24 



If present in the host controller, the host controller shall apply the access condition of RO to 
VERSION HARD. 



R07.25 



If present in the host controller, the host controller shall use a value for VENDOR_NAME of maximum 
length 20 bytes with UTF8 coding. 



R07.26 



If present in the host controller, the host controller shall apply the access condition of RO to 
VENDOR NAME. 



RQ7.27 



If present in the host controller, the host controller shall use a value for MODEL_ID of length 1 byte. 



R07.28 



If present in the host controller, the host controller shall apply the access condition of RO to 
MODEL ID. 



R07.29 



If present in the host controller, the host controller shall apply the access condition of RO to 
HCI VERSION 



The host controller shall use a value for GATES_LIST containing the list of all gates that accept 
dynamic pipes as an array of gate identifiers. 



RQ7.30 



R07.31 



The host controller shall apply the access condition of RO to GATES_LIST. 

A host controller according to the present document shall set the HCI_VERSION parameter if provided 
to '01'. 



R07.32 



NOTE 1 : Development of test cases for RQ4.26 is FFS. 

NOTE 2: RQ7.19 is not tested within this clause, as the registry contains no writeable parameters which can be 

used to test the persistence of the registry. 
NOTE 3: RQ7.20 is also covered in clause 4.3 of TS 1 02 622 [1], covered by clause 5.1 .3 of the present 
document. This RQ is therefore not tested within this clause, as it is effectively tested in clause 5.1 .3. 
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5.4.2.3.1.2 



Test case 1 : registry parameters - optional registries 



5.4.2.3.1.2.1 Test execution 

The test procedure shall be executed for each of the parameters in the following table. 



Registry parameter 

(designated 
REG PARAM) 


Presence 


Expected value 

(designated VALUE) 




RQ to be 

checked in 

steps 2 and 6 


RQ to be 

checked in 

step 4 


VERSION SW 





V VERSION SW 




RQ7.21 


RQ7.22 


VERSION HARD 





V VERSION HARD 




R07.23 


R07.24 


VERSION NAME 





V VERSION NAME 




R07.25 


R07.26 


MODEL ID 





V MODEL ID 




R07.27 


R07.28 



5.4.2.3.1 .2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host controller's identity management gate, and is open. 

5.4.2.3.1.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS ^ HCUT 


Send ANY GET PARAMETER(REG PARAM) on PIPE ID MAN. 




2 


HCUT^HS 


If REG_PARAM is supported by the device under test as indicated in table 4.3, 
send ANY_OK with parameter value equal to VALUE. 

If REG_PARAM is not supported by the device under test as indicated in table 4.3, 
send response containing an allowed error response code for the command. 


See test 

execution 

clause 



5.4.2.3.2 



Remote registry 



5.4.2.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7.1.3. 

NOTE: This clause covers the conformance requirements contained within TS 102 622 [1], clause 7. 1.3 for the 
remote registry. The requirements for the local registry are contained in clause 5.4.2.3.1. 



R07.33 



The host controller shall adhere to the access condition of RO for VERSION SW in the host. 



R07.34 



The host controller shall adhere to the access condition of RO for VERSION HARD in the host. 



R07.35 



The host controller shall adhere to the access condition of RO for VENDOR NAME in the host. 



R07.36 



The host controller shall adhere to the access condition of RO for MODEL ID in the host. 



R07.37 



The host controller shall adhere to the access condition of RO for HCI VERSION in the host. 



R07.38 



The host controller shall adhere to the access condition of RO for GATES LIST in the host. 



R07.39 



The host controller shall manage backward compatibility with previous HCI versions and use only 
commands and parameters defined in the specification having the lower HCI version number between of 
the 2 hosts involved in a transaction. 



RO7.40 



A host controller connected to a host with higher HCI version number shall operate according to its own 
version. 



NOTE 1 : RQ7.33, R07.34, R07.35, RQ7.36, RQ7.37 and R07.38 are not tested, as they are non-occurrence 

RQs. 
NOTE 2: In the current version of the present document, there are no previous HCI versions. RQ7.39 is therefore 

not tested in the current version of the present document. 
NOTE 3: Development of test cases for RQ7.40 is FFS. 
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Loop back gate 



5.4.2.4.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.4 and 4.5. 



Registry parameters which are in the range of '00' to 'EF' but which are not allocated in TS 102 622 [1] 
shall not be present in the registry. 



RQ4.26 



4.5 



NOTE: Development of test cases for RQ4.26 is FFS. 



5.4.3 Generic gates 

Reference: TS 102 622 [1], clause 7.2. 
There are no conformance requirements for the terminal for the referenced clause. 



5.5 HCI procedures 
5.5.1 Pipe management 



5.5.1.1 



Pipe creation 



5.5.1 .1 .1 Conformance requirements 

Reference: TS 102 622 [1], clauses 8.1.1, 5.1,6.1.3.1 and 6.1.3.2. 
These conformance requirements shall be interpreted in the context of the SDL diagram in clause A.2. 



RQ6.22 


When the host controller receives an ADIVI_CREATE_PIPE command, it shall use the WHITELIST 
defined by the destination host in order to verify that the source host is authorized to create a pipe. 


RQ8.1 


The host controller shall verify that the destination host's administration gate WHITELIST contains 
the host identifier of the source host. If the host identifier of the source host is not part of the 
WHITELIST of the destination host, the host controller shall send 

ANY_E_PIPE_ACCESS_DENIED response to the source host and stop any further processing of 
this command. 


RQ8.2 


If the source host's host identifier is part of the WHITELIST of the destination host, the host 
controller shall continue with the procedure. 


RQ8.3 


The host controller assigns an unused pipe identifier. 


RQ8.4 


The host controller notifies the destination host that the source host requested the creation of 
PIPE,. 


RQ6.24 


When the host controller sends an ADM_NOTIFY_PIPE_CREATED command, the command 
parameters shall be 5 bytes long. 


RQ6.25 


When the host controller sends an ADIVI_NOTIFY_PIPE_CREATED command as a result of an 
ADMCREATEPIPE command being received from a host, the source Hid in the command 
parameters shall be the Hid of that host. 


RQ6.23 


When the pipe was successfully created, the host controller shall send the response ANY_OK in 
response to the ADM CREATE PIPE command, with parameters as specified in TS 102 622 [1]. 


RQ8.5 


The host controller responds to ADM_CREATE_PIPE that PIPE, has been created. 


RQ8.6 


When the host controller wants to create a pipe then the pipe identifier is assigned and only steps 2 
and 3 in Figure 6 of TS 102 622 [1] are needed. 


RQ8.7 


When a pipe is created towards the host controller then only steps 1 and 4 in Figure 6 of 
TS 102 622 [1] are needed. 


RQ8.8 


If the host controller does not accept the creation of the pipe, it shall respond to 
ADIVI CREATE PIPE with an appropriate response code. 


RQ5.4 


When it receives a packet from a host, the host controller uses the value of P|q to forward a packet 
to the destination host. 
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RQ5.5 



When it receives a packet from a host, the host controller shall verify that the pipe identifier is used 
by a host involved in the creation of the pipe. 



NOTE 1 : RQ6.22 is contained with RQ8.1 and RQ8.3; it is therefore not explicitly tested within this clause. 
NOTE 2: RQ8.4 and R06.25 are not currently tested, as they require access to the interfaces between two 

hosts and the host controller. 
NOTE 3: RQ8.5 is a duplicate of RQ6.23; it is therefore not explicitly tested within this clause. 



5.5.1 .1 .2 Test case 1 : valid pipe creation from host simulator to another host 

5.5.1.1.2.1 Test execution 

Assignment of terms to entities referenced in SR2: Hid of host = HOST_X. 
There are no test case-specific parameters for this test case. 

5.5.1.1.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is open. 



5.5.1.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS-> HCUT 


Send ADM_CREATE_PIPE on PIPEl, with source Gid = 'EE', destination Hid 
= HOST X and destination Gid = Gid of identity management gate. 




2 


HCUT-^ HS 


Send ANY_OK, with parameters of 5 bytes as follows: 

• Source Hid = Hid of host simulator. 

• Source Gid = source Gid in command. 

• Destination Hid = destination Hid in command. 

• Destination Gid = destination Gid in command. 

• PiD = a previously unallocated Pid. 
Designate the create pipe PIPE ID MAN. 


RQ8.2, 

RQ8.3, 

R06.23, 

RQ8.7 


3 


HS-^ HCUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




4 


HCUT^ HS 


Send ANY OK. 




5 


HS^ HCUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




6 


HCUT^ HS 


Send ANY_OK (parameters are not checked). 


RQ5.4, 
RQ5.5 



5.5.1 .1 .3 Test case 2: pipe creation from host simulator to another host, host simulator not 

in other host's WHITELIST 

5.5.1.1.3.1 Test execution 

Assignment of terms to entities referenced in SR3: Hjd of host = HOST_X. 
There are no test case-specific parameters for this test case. 

5.5.1.1.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is open. 

5.5.1.1.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS ^ HCUT 


Send ADM_CREATE_PIPE on PIPEl, with source Gid = 'EE', destination 
Hid = HOST X and destination Gid = Gid of identity management gate. 




2 


HCUT ^ HS 


Send ANY E PIPE ACCESS DENIED. 


RQ8.1 
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Test case 3: pipe creation from host simulator to another host, other host rejects 
pipe creation 



5.5.1.1.4.1 Test execution 

Assignment of terms to entities referenced in SR4: Hid of host = HOST_X, and Gm of gate = GATE_X. 
There are no test case-specific parameters for this test case. 

5.5.1.1.4.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is open. 

5.5.1.1.4.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send ADM_CREATE_PIPE on PIPE1, with source Gid = 'EE', destination 
Hid = HOST X and destination Gid = GATE X. 




2 


HCUT^ HS 


Send response containing an allowed error response code for the command. 


RQ6.23 



5.5.1 .1 .5 Test case 4: valid pipe creation from host controller to host simulator 

5.5.1.1.5.1 Test execution 

There are no test case-specific parameters for this test case. 

5.5.1.1.5.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is open. 

• Host simulator's GATE_LIST includes all valid Gid. 

5.5.1.1.5.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ HCUT 


Trigger the host controller to create a pipe to any gate which exists in the 
host simulator's GATE LIST. 




2 


HCUT ^ HS 


Send ADM_NOTIFY_PIPE_GREATED on PIPEl, with parameters 5 bytes 
long, as follows: 

• Source Hid = Hid of host controller. 

• Source Gid = valid Gid. 

• Destination Hid = Hid of host simulator. 

• Destination Gid = Gid in the host simulator's GATE_LIST. 

• Pid = a previously unallocated Pid. 
Designate the created pipe PIPE X. 


RQ8.3, 

R06.24, 

RQ8.6 


3 


HS^ HCUT 


Send ANY OK (parameters are not checked). 




4 


HCUT ^ HS 


Wait for a reasonable delay for the host controller to send a command on 

PIPE_X. 

If the host controller sends a command on PIPEX, consider the test passed. 

If the host controller does not send a command on PIPEX, perform steps 5 

and 6. 




5 


HS^ HCUT 


Send ANY OPEN PIPE on PIPE X. 




6 


HGUT^ HS 


Send ANY OK. 
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5.5.1 .1 .6 Test case 5: pipe creation from host simulator to host controller, pipe not 

supported by host controller 

5.5.1.1.6.1 Test execution 

Assignment of terms to entities referenced in SR5: Gid of gate = GATE_X 
There are no test case-specific parameters for this test case. 

5.5.1.1.6.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is open. 

5.5.1.1.6.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send ADM_CREATE_PIPE on PIPE1, with source Gid = 'EE', destination Hid 
= Hid of host controller and destination Gid = GATE X. 




2 


HCUT^ HS 


Send response containing an allowed error response code for the command. 


RQ8.8 



5.5.1.2 



Pipe deletion 



5.5.1.2.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 8.1.2, 6.1.3.3 and 6.1.3.4. 
These conformance requirements shall be interpreted in the context of the SDL diagram in clause A. 3. 



RQ8.9 



After receiving a valid ADM_DELETE PIPE command from a host, the host controller notifies the 
destination host (with an ADM_NOTIFY_PIPE_DELETED command). 



RQ6.28 



When the host controller sends an ADM_NOTIFY_PIPE_DELETED command, the command 
parameters shall be 1 byte long. 



RQ6.26 



The host that requested the deletion of the pipe can only be the source host or destination host. 



RQ6.27 



When the pipe is successfully deleted, the host controller shall send the response ANY_OK without 
parameters. 



RQ8.10 



When PIPEx connects to a gate at the host controller and the connecting host requests the deletion, 
then only steps 1 and 4 in Figure 8 of TS 102 622 [1] are needed. 



RQ8.11 



When PIPEx connects to a gate at the host controller and the host controller requests the deletion, then 
only steps 2 and 3 in Figure 8 of TS 102 622 [1] are needed. 



NOTE: Development of test cases for RQ8.9, RQ8.1 0, RQ8.1 1 and RQ6.28 is FFS. 



5.5.1.2.2 



Test case 1 : valid pipe deletion from host simulator to another host 



5.5.1.2.2.1 Test execution 

Assignment of terms to entities referenced in SR2: Hid of host = HOST_X. 
There are no test case-specific parameters for this test case. 

5.5.1.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is open. 

• A pipe (PIPE_X) has been created between a gate on the host simulator and a gate on HOST_X, and is 
currently open. 
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5.5.1.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS -» HCUT 


Send ADM DELETE PIPE{PIPE X)onPIPE1. 




2 


HCUT-»HS 


Send ANY_OK with no parameters. 


RQ6.26 
RQ6.27 



5.5.1.3 



Clear all Pipes 



5.5.1.3.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 8.1.3,6.1.3.5 and 6.1.3.6. 



RQ6.29 



When the host controller receives a valid ADM_CLEAR_ALL_PIPE command and the data link layer 
specified in TS 102 613 [2] is used, it shall interpret the two bytes in the command parameters as the 
identity reference data, and shall use the identity reference data to initialize the reference data used by 
the host controller to check the UICC host identity. 



RQ6.30 



When the host controller receives a valid ADM_CLEAR_ALL_PIPE command, it shall delete all the 
dynamic pipes connected to the requesting host, close all static pipes connected to the requesting host 
and set all registry values related to static pipes connected to the requesting host to their default values. 



RQ6.31 



When ADIVICLEARALLPIPE is successful the host controller shall respond with an ANYOK without 
parameters. 



RQ6.32 



When the host controller receives a valid ADIVI_CLEAR_ALL_PIPE command from a requesting host, it 
shall send ADM_NOTIFY_ALL_PIPE_CLEARED to every host with at least one pipe to the requesting 
host. 



RQ6.33 



When the host controller sends an ADM_NOTIFY_ALL_PIPE_CLEARED command with the host 
controller as the requesting host, it shall delete all dynamic pipes between the host controller and the 
host and shall close all static pipes between the host and the host controller. 



RQ6.34 



When the host controller sends an ADM_NOTIFY_ALL_PIPE_CLEARED command, the command 
parameters shall be one byte long and shall contain the Hip of the requesting host. 



5.5.1 .3.2 Test case 1 : clear all pipes from host controller - static pipes, dynamic pipes to 

host 

5.5.1.3.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.5.1.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PlPEl is open. 

• A pipe (PIPE_LOOP_BACK) has been created to the host controller's loop back gate, and is currently open. 
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5.5.1.3.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User^ 
HCUT 


Trigger the host controller to send ADM_NOTIFY_ALL_PIPE_CLEARED, 
with the host controller as the requesting host. 




2 


HCUT^ HS 


Send ADM_NOTIFY_ALL_PIPE_CLEARED, with the host controller as 
the requesting host. 


RQ6.34 


3 


HS^ HCUT 


Send ANY OK. 




4 


HCUT^ HS 


Wait for a reasonable delay for the host controller to send a command on 

PIPE1. 

If host controller sends a command on PIPE1 , perform step 5. 

If host controller does not send a command on PIPE1 , perform steps 6 to 

9. 




5 


HCUT^ HS 


Check that the command sent in step 3 is ANY OPEN PIPE (see note). 


RQ6.33 


6 


HS^ HCUT 


Send ADI\/I_CREATE_PIPE on PIPE1 , with source and destination 
GiD = GiD of identity management gate. 




7 


HCUT^ HS 


Send response containing an allowed error response code for the 
command. 


RQ6.33 


8 


HS -> HCUT 


Send ANY OPEN PIPEonPIPEI. 




9 


HCUT^ HS 


Send ANY OK. 


RQ6.33 


NOTE: The host simulation shall respond appropriately to this command, independently of what command 
has been sent. 



5.5.2 Registry access 

Reference: TS 102 622 [1], clause 8.2. 
There are no new conformance requirements for the terminal for the referenced clause. 

5.5.3 Host and Gate discovery 

Reference: TS 102 622 [1], clause 8.3. 
There are no conformance requirements for the terminal for the referenced clause. 

5.5.4 Session initialization 



5.5.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 8.4. 



R06.29 



In case the lower layer identity check fails, the host controller shall execute only the following commands: 
ANY_OPEN_PIPE, ADI\/I_CLEAR_ALL_PIPE, ANY_GET_PARAMETER, and only if these are sent on 
PIPE.. 



RO6.30 



In case the lower layer identity check fails, the host controller shall return ANY_E_INHIBITED to all 
commands, except for ANY_OPEN_PIPE, ADIVI_CLEAR_ALL_PIPE, ANY_GET_PARAMETER on 
PIPE.. 



R06.31 



In case the lower layer identity check fails, the host controller shall ignore all events on all pipes. 



R06.32 



In case the lower layer identity check fails, the host controller shall return the default value of the 
SESSIONJDENTITY. However the value of the SESSIONJDENTITY in the registry remains 
unchanged. 



R06.33 



The inhibited state shall be terminated after processing a valid ADIVI_CLEAR_ALL_PIPE command. 
In case the lower layer identity check passes, the host controller shall not enter the inhibited state. 



R06.34 
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5.5.5 Loop back testing 

5.5.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 8.5. 



RQ8.18 



The host controller shall accept the creation of a pipe to its loop back gate from any gate in another host. 



RQ8.19 



When the host controller receives the event EVT_POST_DATA on a pipe connected to its loop back 
gate, it shall send back the event EVT_POST_DATA with same data as received in the received 
EVT POST DATA. 



RQ8.20 



The loopback gate shall support at least all messages with size up to 250 bytes. 



5.5.5.2 



Test case 1 : pipe creation 



5.5.5.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• Source Gm values of: '00', '03', '05', '10', 'AA', 'FF'. 

5.5.5.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PlPEl is open. 

5.5.5.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send ADM_CREATE_PIPE on PIPE1 , with source Gid as specified and 
destination Gid = Gid of loop back gate. 




2 


HCUT^ HS 


Send ANY OK (parameters are not checked). 


R08.18 



5.6 



Contactless card emulation 



5.6.1 Overview 

5.6.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.1. 



RQ9.1 



The CLF shall handle the RF communication layers to the external contactless reader. 



RQ9.2 



The host controller has one card RF gate for each RF technology it supports. 



RQ9.3 



For the contactless platform for card emulation mode the pipes to card RF gates shall be created, 
opened, closed and deleted by the host. 



RQ9.4 



The RF technology of a card RF gate is active when there is an open pipe connected to it. 



RQ9.5 



The host controller shall activate one or more RF technologies as requested by the host to the external 
reader. 



NOTE: Development of test case for R09.3 is FFS. 



5.6.2 Void 

Reference: TS 102 622 [1], clause 9.2. 
There are no conformance requirements for the terminal for the referenced clause. 
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5.6.3 Gates 

5.6.3.1 Void 

Reference: TS 102 622 [1], clause 9.3.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.3.2 Identity management gate 
5.6.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.2. 



RQ9.6 



If low power mode is supported, the parameter LOW_POWER_SUPPORT of identity management gate 
shall be '01'. 



RQ9.7 



If low power mode is not supported, the parameter LOW_POWER_SUPPORT of identity management 
gate shall be '00'. 



RQ9.8 



The host controller shall apply the access condition of RO to LOW_POWER_SUPPORT. 



5.6.3.3 Card RF gates 

5.6.3.3.1 Overview 

Reference: TS 102 622 [1], clause 9.3.3.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.3.3.2 Commands 

5.6.3.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.2. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.3.3.3 Events and subclauses 

5.6.3.3.3.1 Events 

5.6.3.3.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.3. 



RQ9.10 [The Card RF gates shall support the EVT_SEND_DATA event. 



NOTE: RQ1 is tested in clause 5.6.4. 



5.6.3.3.3.2 EVT_SEND_DATA 

Reference: TS 102 622 [1], clause 9.3.3.3.1. 
There are no conformance requirements for the terminal for the referenced clause. 



£75/ 



Release 8 



38 



ETSI TS 102 695-3 V8.3.0 (2012-12) 



5.6.3.3.4 Registry and subclauses 

5.6.3.3.4.1 Registry 



5.6.3.3.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4. 



RQ9.1 1 |AII registries shall be persistent. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.6.3.3.4.2 



RF technology type A 



5.6.3.3.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4.1. 



RQ9.12 



The CLF shall only accept values of MODE of 'FF' and '02' 



R09.13 



The CLF shall set a default value for MODE of 'FF'. 



R09.14 



The CLF shall apply the access condition of RW for MODE. 



R09.15 



The CLF shall use a default value for UID_REG of length zero bytes 



R09.16 



If Length of UID_REG equals then the CLF generates a single size DID with uidO : 
as random numbers. 



'08'and uidi to uid3 



R09.17 



The random numbers shall be generate only on state transitions POWER_OFF to IDLE state (state 
definitions according to ISO/IEC 14443-3 [6]) The CLF shall interpret the absence of an RF-field as 
POWER-OFF state. 



R09.18 



If Length equals 4, 7 or 1 then the CLF shall use UID_REG as DID. 



R09.19 



The CLF shall apply the access condition of WO for UID_REG. 



RQ9.20 



The CLF shall set a default value for SAK of '00'. 



RQ9.21 



The CLF shall apply the access condition of RW for SAK 



R09.22 



The CLF shall set a default value for ATOA of '0000'. 



R09.23 



The CLF shall apply the access condition of RW for ATOA. 



R09.24 



The CLF shall set a default value for APPLICATION DATA of 'N1 =0'. 



RQ9.25 



The CLF shall apply the access condition of RW for APPLICATION_DATA. 



R09.26 



The CLF shall set a default value for FWI, SFGI of 'EE'. 



R09.27 



The CLF shall apply the access condition of RW for FWI, SFGI. 



R09.28 



If CID_SUPPORT ='01 ' the CLF shall set CID support in the ATS. 



R09.29 



Void 



RO9.30 



The CLF shall set a default value for CID SUPPORT of '00'. 



R09.31 



The CLF shall apply the access condition of RW for CID_SUPPORT. 



R09.32 



If the CLF contains a tunneling mode capability for type A ISO/IEC 14443-4 [7] non compliant protocol 
support then the value of CLT_SUPPORT shall be '01 '. 



R09.33 



If the CLF does not contain a tunneling mode capability for type A ISO/IEC 14443-4 [7] non compliant 
protocol support then the value of CLT_SUPPORT shall be '00'. 



R09.34 



The CLF shall apply the access condition of RO to CLT_SUPPORT 



R09.35 



The host controller shall support DATARATE_MAX which codes maximum divisor supported with coding 
as defined in TS 102 622 [1] where: 

• Byte 1 defines the maximum divisor supported in direction PCD to PICC. 

» Byte 3 defines the limitation to support different divisors for each direction. 



R09.36 



The CLF shall set a default value for DATARATE MAX of '030300'. 



R09.37 



The CLF shall apply the access condition of RW for DATARATE_MAX. 



R09.38 



The CLF shall use the minimum of the value indicated in the registry and the maximum divisor 
implemented in the CLF as the maximum support divisor indicated in TA (1) as defined in ISO/IEC 
14443-4(7]." 



R09.39 



Registry parameters which are in the range reserved for usage by TS 1 02 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



NOTE 1 : Development of test cases for RO 9.39 is FFS. 

NOTE 2: Development of test cases for RO 9.32, RO 9.33 and RQ 9.34 is FFS. 
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5.6.3.3.4.2.2 Test case 1 : MODE parameter 

5.6.3.3.4.2.2.1 Test execution 

There is no test case specific parameters for this test case. 

5. 6.3.3.4.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source Gid = '23' to the card RF gate of type A. 

5. 6.3.3.4.2.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send ANY GET PARAMETER (MODE) on PIPEa. 




2 


HCUT^ HS 


Send ANY_OK with value of 'FF'. 


R09.13, 
RQ9.14 


3 


HS-» HCUT 


Send ANY SET PARAMETER (MODE, '02') on PIPEa. 




4 


HCUT-» HS 


Send ANY_OK. 


R09.12, 
RQ9.14 


5 


HS^ HCUT 


Send ANY GET PARAMETER (MODE) on PIPEa. 




6 


HCUT^ HS 


Send ANY_OK with value '02'. 


R09.12, 
RQ9.14 


7 


HS ^ HCUT 


Send ANY SET PARAMETER (MODE, 'FF') on PIPEa. 




8 


HCUT^ HS 


Send ANY_OK. 


R09.12, 
RQ9.14 


7 


HS^ HCUT 


Send ANY GET PARAMETER (MODE) on PIPEa. 




8 


HCUT^ HS 


Send ANY_OK with a parameter value of 'FF'. 


R09.12, 
RQ9.14 



5.6.3.3.4.2.3 Test case 2: UID_REG and SAK - verify parameter 

5.6.3.3.4.2.3.1 Test execution 

The test procedure shall be executed once for each of following parameters: 
UID of length 4, UIDa = 01 02 03 04 and SAKa = 00. 
UID of length 7, UIDa = 01 02 03 04 05 06 07 and SAKa = 20. 
UID of length 10, UIDa = 01 02 03 04 05 06 07 08 09 OA and SAKa = 20. 

5.6.3.3.4.2.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source Gid = '23' to the card RF gate of type A. 

• The Proximity Coupling Device (PCD) supporting ISO/IEC 14443-3 Type A protocol is powered off. 

• MODE is set to 'FF'. 
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5.6.3.3.4.2.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS ^ HCUT 


Send ANY GET PARAMETER (Ul REG) on PIPEa. 




2 


HCUT^ HS 


Send response containing an allowed error response code for the 
command. 


R09.19 


3 


HS^ HCUT 


Send ANY SET PARAMETER (UID, 'UIDa') on PIPEa. 




4 


HCUT^ HS 


Send ANY_OK. 


R09.18, 
R09.19 


5 


HS^ HCUT 


Send ANY GET PARAMETER (SAK) on PIPEa. 




6 


HCUT^ HS 


Send ANY_OK. 


RO9.20, 
R09.21 


7 


HS ^ HCUT 


Send ANY SET PARAMETER (SAK, 'SAKa') on PIPEa. 




8 


HCUT^ HS 


Send ANY OK. 


R09.21 


9 


HS-> HCUT 
HCUT^ HS 


Set the MODE parameter to '02' 




10 


User^PCD 


The terminal is placed in PCD field. 




11 


PCD ^ HCUT 


Transitions from POWER OFF to IDLE state. 




12 


PCD ^ HCUT 


Send REOA. 




13 


HCUT ^ PCD 


Send ATOA and enter READY state. 




14 


PCD ^ HCUT 


Send AC command with appropriate cascade level. 




15 


HCUT ^ PCD 


Send UID CLn given in step 3. 


R09.18 


16 


PCD ^ HCUT 


Send SELECT command with received UID. 




17 


HCUT -» PCD 


Send: 

• SAKa (UID is complete). 

• SAK (UID is not complete): repeat the steps 14 to 17. 


R09.18, 
R09.21 


18 


User ^ HCUT 


The terminal is removed from the PCD field. 




19 


User ^ HCUT 


The terminal is placed in PCD field. 




20 


PCD ^ HCUT 


Transitions from POWER OFF to IDLE state. 




21 


PCD ^ HCUT 


Send REOA. 




22 


HCUT ^ PCD 


Send ATOA and enter READY state. 




23 


PCD ^ HCUT 


Send AC command with appropriate cascade level. 




24 


HCUT ^ PCD 


Send UID CLn given in step 3. 


R09.18 


25 


PCD ^ HCUT 


Send SELECT with received UID. 




26 


HCUT^ PCD 


Send: 

• SAKa (UID is complete). 

• SAK (UID is not complete): repeat the steps 23 to 26. 


R09.18, 
R09.21 



5.6.3.3.4.2.4 



Testcase3:FWI, SFGI 



5.6.3.3.4.2.4.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• SFGI_1 = 4. 

• FWI_1 = 8. 

5.6.3.3.4.2.4.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source Gid = '23' to the card RF gate of type A. 

• MODE is set to 'FF' and SAK is set to '20'. 
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5.6.3.3.4.2.4.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS -^ HCUT 


Send ANY SET PARAMETER (FWI, SFGI, 'FWI 1 SFG 1')onPIPEa 




2 


HCUT ^ HS 


Send ANY OK 


RQ9.27 


3 


HS ^ HCUT 


Send ANY GET PARAMETER (FWI, SFGI) on PIPEa 




4 


HCUT^HS 


Send ANY OK with value 'FWI 1 SFG 1' given in step 1 


RQ9.27 


5 


HS ^ HCUT 
HCUT ^ HS 


Set the MODE parameter to '02' 




6 


PCD ^ HCUT 
HCUT^ PCD 


Perform initialization of RF ISO/IEC 14443-3 [6] Type A (with anti-collision 
and selection). 




7 


PCD ^ HCUT 


Send RATS 




8 


HCUT^ PCD 


Send ATS with value (TB(1)) given in step 1 


RQ9.27 



5.6.3.3.4.3 



RF technology type B 



5.6.3.3.4.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4.2. 



RQ9.40 



Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



RQ9.41 



The CLF shall only accept values of MODE of 'FF' and '02'. 



R09.42 



The CLF shall set a default value for MODE of 'FF'. 



RQ9.43 



The CLF shall apply the access condition of RW for MODE. 



RQ9.44 



The CLF shall only accept values of PUP! of length or 4 bytes. 



RQ9.45 



If N=0 then the CLF shall generate the PUP! as dynamically generated number. 



RQ9.46 



The PUPI shall only be generated by a state transition from the POWER-OFF to the IDLE state(state 
definitions according to ISO/IEC 14443-3 [6]). 



R09.47 



The CLF shall interpret the absence of an RF-field as POWER-OFF state. 



R09.48 



If N is not equal to 0, the CLF shall use the PUPI_REG as PUPI. 



R09.49 



The CLF shall apply the access condition of WO for PUPI_REG. 



RQ9.50 



The CLF shall use the AFI registry parameter as AFI according to ISO/IEC 14443-3 [6]. 



R09.51 



The CLF shall set a default value for AFI of '00'. 



R09.52 



The CLF shall apply the access condition of RW to AFI. 



R09.53 



The CLF shall set a default value for ATOB of '00 00 00 E4. 



R09.54 



The CLF shall only accept values of ATOB of length 4 bytes. 



R09.55 



The CLF shall set additional data for ATOB as defined in the registry Table 31 of TS 1 02 622 [1 ]. 



R09.56 



The CLF shall apply the access condition of RW to ATOB. 



R09.57 



The CLF shall set higher layer response in answer to ATTRIB command as defined registry. 



RQ9.58 



The CLF shall set a default value for HIGHER LAYER RESPONSE of 'N2=0'. 



R09.59 



The CLF shall apply the access condition of RW for HIGHER_LAYER_RESPONSE. 



RO9.60 



The host controller shall support DATARATE_MAX which codes maximum bit rates supported with 
coding as defined in TS 102 622 [1] where: 

• Byte 1 defines the maximum bit rates supported in direction PCD to PICC. 

» Byte 3 defines the limitation of having the bit rate in both direction. 



R09.61 



The CLF shall set a default value for DATARATE MAX of '030300'. 



R09.62 



The CLF shall apply the access condition of RW for DATARATE_MAX. 



R09.63 



The CLF shall set a default value for ATOB of length 0. 



R09.64 



The CLF shall use the minimum of the value indicated in the registry and the maximum bit rate supported 
implemented in the CLF as the maximum bit rate indicated in the first byte of the protocol information as 
defined in ISO/IEC 14443-3 [6]. 



NOTE: Development of test cases for RO9.40 and R09.64 is FFS. 



5.6.3.3.4.3.2 



Test case 1 : MODE parameter 



5.6.3.3.4.3.2.1 Test execution 

There is no test case specific parameters for this test case. 
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5. 6.3.3.4.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source Gjd = '21' to the card RF gate of type B. 



5. 6.3.3.4.3.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send ANY GET PARAMETER (MODE) on PIPEa 




2 


HCUT^ HS 


Send ANY_OK with value 'FF' 


R09.42, 
RQ9.43 


3 


HS ^ HCUT 


Send ANY SET PARAMETER (MODE, '02') on PIPEa 




4 


HCUT-> HS 


Send ANY_OK 


R09.41 , 
RQ9.43 


5 


HS^ HCUT 


Send ANY GET PARAMETER (MODE) on PIPEa 




6 


HCUT^ HS 


Send ANY OK with value '02' 


RQ9.43 


7 


HS ^ HCUT 


Send ANY SET PARAMETER (MODE, 'FF') on PIPEa 




8 


HCUT^ HS 


Send ANY_OK 


R09.41, 
RQ9.43 


7 


HS ^ HCUT 


Send ANY GET PARAMETER (MODE) on PIPEa 




8 


HCUT^ HS 


Send ANY OK with value 'FF' 


RQ9.43 



5.6.3.3.4.4 



RF technology type B' 



5.6.3.3.4.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4.3. 
NOTE: Defining conformance requirements is out of scope of the present document. 



5.6.3.3.4.5 



RF technology Type F (ISO18092 212 kbps/424 kbps card emulation only) 



5.6.3.3.4.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4.4. 



RQ9.85 



Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



R09.66 



The CLF shall only accept values of MODE of 'FF' and '02'. 



R09.67 



The CLF shall set a default value for MODE of 'FF'. 



R09.68 



The CLF shall apply the access condition of RW for MODE. 



RQ9.69 



The CLF shall support the capabilities indicated in the SPEED_CAP parameter as specified in 
TS102 622[1]. 



RQ9.70 



The CLF shall apply the access condition of RO to SPEED_CAP. 



R09.71 



The CLF shall contain a tunnelling mode capability for type F card emulation anti-collision support if 
CLT SUPPORT='01'. 



R09.72 



The CLF shall not contain a tunnelling mode capability for type F card emulation anti-collision support if 
CLT SUPPORT ='00'. 



R09.73 



The CLF shall apply the access condition of RO to CLT_SUPPORT. 



NOTE: Development of test cases for above listed ROs is FFS. 



5.6.3.4 



Card application gates 



5.6.3.4.1 Overview 

Reference: TS 102 622 [1], clause 9.3.4.1. 
There are no conformance requirements for the terminal for the referenced clause. 
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5.6.3.4.2 Commands 

5.6.3.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.2. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.3.4.3 Events and subclauses 

5.6.3.4.3.1 Events 

5.6.3.4.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3. 



RQ9.74 [When sending to a card application gate, the CLF shall respect the values and events as listed. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.6.3.4.3.2 EVT_FIELD_ON 

5.6.3.4.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.1. 



RQ9.75 



When EVTFIELDON is sent by the host controller, it shall be sent within 2 ms after the detection of an 
RF field. 



RQ9.76 



In case of an underlying data link layer according to TS 102 613 [2], if SWP is in DEACTIVATED state, 
the CLF shall activate the interface instead of sending the EVT_FIELD_ON. 



RQ9.77 [When the host controller sends EVT_FIELD_ON, it shall not contain parameters. 



NOTE: Development of test cases for RQ9.75 & RQ9.77 is FFS. 



5.6.3.4.3.3 EVT_CARD_DEACTIVATED 

5.6.3.4.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.2. 



RQ9.78 [When the host controller sends EVT_CARD_DEACTIVATED, it shall not contain parameters. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.6.3.4.3.4 EVT_CARD_ACTIVATED 

5.6.3.4.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.3. 



R09.79 [When the host controller sends EVT_CARD_ACTIVATED, it shall not contain parameters. 



NOTE: Development of test cases for above listed RQs is FFS. 
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5.6.3.4.3.5 



EVT FIELD OFF 



5.6.3.4.3.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.4. 



RQ9.80 [When the host controller sends EVT_FIELD_OFF, it shall not contain parameters. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.6.3.4.3.6 



EVT SEND DATA 



5.6.3.4.3.6.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.5. 



RQ9.81 |0n sending EVT_SEND_DATA the CLF shall set the last parameter byte as RF error indicator. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.6.3.4.4 



Registry 



5.6.3.4.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.4. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.4 Procedures 



5.6.4.1 



Use of contactless card application 



5.6.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.1. 

NOTE: These requirements apply for usage of ISO/lEC 14443-4 [7] . 



RQ9.82 



In full power mode, when the CLF detects a RF field, the card RF gate shall send the event 
EVT_FIELD_ON to the card application gate unless otherwise as specified in clause 9.3.4.3.1 . 



RQ9.83 



When there are multiple open card RF gates the CLF shall send the EVT_FIELD_ON to the open card 
application gate with the lowest Gip. 



RQ9.84 



When the CLF detects a RF field, and after sending EVT_FIELD_ON (if sent), the CLF shall start the 
initialization and anti-collision process as defined in ISO/lEC 14443-3 [6] using the parameters from the 
appropriate card RF gate registry for the present RF technology. 



RQ9.85 



If The card RF gate sends EVT_CARD_ACTIVATED to the card application gate, it shall send it at the 
end of the activation sequence as defined ISO/lEC 14443-4 [7]. 



RQ9.86 



The card RF gate shall forward the C-APDUs from the external contactless reader to the card application 
gate using the EVT_SEND_DATA. 



RQ9.87 



If the CLF detects the end of the PICC deactivation sequence by the external contactless reader, the 
card RF gate shall send an EVT_CARD_DEACTIVATED. 



RQ9.88 



In full power mode, when the CLF detects at any time during the sequence that the RF field is off, the 
card RF gate shall send EVT_FIELD_OFF to the card application gate. 



RQ9.89 



When there are multiple open cards RF gates the CLF shall send the EVT_FIELD_OFF to the card 
application gate used during the transaction or to the open card application gate with the lowest Gip. 
In low power mode, when the CLF detects at any time during the sequence that the RF field is off, the 
card RF gate shall either send EVT_FIELD_OFF to the card application gate or power down the host. 
Development of test cases for RQ9.83, RQ9.89 is FFS. 



RQ9.90 



NOTE: 
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5.6.4.2 



Non ISO/IEC 14443-4 type A 



5.6.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.2. 



RQ9.91 



In full power mode, and if SWP is not in DEACTIVATED_state, when the CLF detects a RF field, the card 
RF gate shall send the event EVT_FIELD_ON to the card application gate. 



RQ9.92 



When there are multiple open card RF gates the CLF shall send the EVT_FIELD_ON to the open card 
application gate with the lowest Gip. 



RQ9.93 



When the CLF detects a RF field, and after sending EVT_FIELD_ON (if sent), the CLF shall start the 
initialization and anti-collision process as defined in ISO/IEC 14443-3 [6] using the parameters from the 
card RF gate registry for the RF technology type A. 



RQ9.94 



Any other communications are done using the CLT mode as defined in TS 1 02 61 3 [2], 



RQ9.95 



In full power mode, when the CLF detects at any time during the sequence that the RF field is off, the 
card RF gate shall send EVT_FIELD_OFF to the card application gate. 



RQ9.96 



When there are multiple open cards RF gates the CLF shall send the EVT_FIELD_OFF to the card 
application gate used during the transaction or to the open card application gate with the lowest Gip. 
In low power mode, when the CLF detects at any time during the sequence that the RF field is off, the 
card RF gate shall either send EVT_FIELD_OFF to the card application gate or power down the host. 
Development of test cases for above listed RQs is FFS. 



RQ9.97 



NOTE: 



5.6.4.3 



Type B' RF technology 



5.6.4.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.3. 

NOTE: Defining conformance requirements is out of scope of the present document. 

5.6.4.4 Type F RF technology 



5.6.4.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.4. 



RQ9.98 



In full power mode, and if SWP is not in DEACTIVATED state, when the CLF detects a RF field, the 
card RF gate shall send the event EVT_FIELD_ON to the card application gate. 



RQ9.99 



When there are multiple open cards RF gates the CLF shall send the EVT_FIELD_ON to the open 
card application gate with the lowest Gip. 



RQ9.100 



In case SWP as defined in TS 102 613 [2] is used as a data link layer, when the CLF detects a RF 
field, and after sending EVT_FIELD_ON (if sent), the CLF shall start the initialization and anti- 
collision process performed using CLT as defined in TS 1 02 61 3 [2] for the RF technology 
ISO/IEC 18092 [4] 212 kbps/424 kbps passive mode type F. 



RQ9.102 



The card RF gate shall forward the ISO/IEC 18092 [4] 212 kbps/424 kbps frames from the external 
reader to the card application gate using the EVT_SEND_DATA with the structure specified in 
TS102 622[1]. 



RQ9.103 



The host sending a response shall encapsulate the ISO/IEC 18092 [4] 212 kbps/424 kbps frames in 
an EVT_SEND_DATA event and shall send it to the card RF gate. 



RO9.104 



In full power mode, when the CLF detects at any time during the sequence that the RF field is off, 
the card RF gate shall send EVT_FIELD_OFF to the card application gate. 



RQ9.105 



When there are multiple open cards RF gates the CLF shall send the EVT_FIELD_OFF to the card 
application gate used during the transaction or to the open card application gate with the lowest Gip. 



RQ9.106 



In low power mode, when the CLF detects at any time during the sequence that the RF field is off, 
the card RF gate shall either send EVTFIELDOFF to the card application gate or power down the 
host. 



RQ9.107 



ISO/IEC 18092 [4] 212 kbps/424 kbps frames, except initialization command and response 
(command code '00' and '01'),shall be exchanged using the appropriate gate depending on the 
command code of the frame as described in TS 102 622 [1], 



RQ9.108 



The command codes reserved for the NFCIP-1 protocol shall not be forwarded. 



NOTE: Development of test cases for above listed RQs is FFS. 
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5.6.4.5 Update RF technology settings 
5.6.4.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.5. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.4.6 Identity checl< 

5.6.4.6.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.6. 



RQ9.110 



If the lower identity check fails, the host controller shall not respond to the external contactless reader 
with any parameter from the card emulation registries related to the UICC host. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.7 



Contactless reader 



5.7.1 



Overview 



5.7.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.1. 



RQ10.1 The host controller has one reader RF gate for each RF technology it supports. 



RQ10.2 



The CLF shall handle the RF layers of the communications as defined in ISO/IEC 14443-2 [5], 



RQ10.3 



The anti-collision and activation as defined in ISO/IEC 14443-3 [6] shall be handled by the CLF 
under the control of the host. 



RQ10.4 



The RF protocol as defined in ISO/IEC 14443-4 [7] shall be handled by the CLF. 



RQ10.5 



The reader RF gate and reader application gate shall exchange APDUs defined in ISO/IEC 7816-4 
[8] over their pipe. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.7.2 Reader RF gates 



5.7.2.1 Overview 

Reference: TS 102 622 [1], clause 10.2.1. 
There are no conformance requirements for the terminal for the referenced clause. 
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5.7.2.2 



Command 



5.7.2.2.1 



WR XCHG DATA 



5.7.2.2.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.2.1. 



RQ10.6 



If b5 of the CTR field of WR_XCHG_DATA is set to zero, application level time-out is deactivated. 



RQ10.7 



If b5 of the CTR field of WR_XCHG_DATA is set to one, then b4 to b1 is a time-out value which shall 
use to calculate the application level time-out with the formula specified in TS 102 622 [1]. 



RQ10.8 



When command WR_XCHG_DATA is successful, the host controller shall respond with ANY_OK 
with parameter which contains the data received and the RF error indicator. 



RQ10.9 



When command WR XCHG DATA is successful, the RF error indicator shall be '00' if no error. 



RQ10.10 



When command WR XCHG DATA is successful, the RF error indicator shall be '01 ' if error. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.7.2.3 



Registries 



5.7.2.3.1 



Type A reader RF gate 



5.7.2.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.3.1. 



RQ10.11 



Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



RQ10.12 



The registry is not persistent. 



RQ10.13 



The values are updated after each target activation. 



RQ10.14 



The CLF shall set a default value for UID REG of '08000000'. 



RQ10.15 



The CLF shal 



apply the access condition of RO for UID. 



RQ10.16 



The CLF shal 



use a default value for ATQA of '0000'. 



RQ10.17 



The CLF shal 



apply the access condition of RO for ATQA. 



RQ10.18 



The CLF shal 



use a default value for APPLICATIONDATA of an empty array. 



RQ10.19 



The CLF shal 



apply the access condition of RO for APPLICATION_DATA. 



RQ10.20 



The CLF shal 



use a default value for SAK of '00'. 



RQ10.21 



The CLF shal 



apply the access condition of RO for SAK. 



RQ10.22 



The CLF shal 



use a default value for FWI, SFGT of 'EE'. 



RQ10.23 



The CLF shal 



apply the access condition of RO for FWI, SFGT. 



RQ10.24 



The CLF shal 



set a default value for DATARATE MAX of '00'. 



RQ10.25 



The CLF shal 



apply to the access condition of RW to DATARATEMAX. 



RQ10.26 



The CLF shall accept valid values of DATARATE_MAX as defined in TS 102 622 [1]. 



RQ10.27 



The maximum supported divisor used over the RF interface shall be the minimum of the value as 
indicated in the registry and the maximum divisor implemented in the CLF. 



NOTE: Development of test cases for above listed RQs is FFS. 
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5.7.2.3.2 



Type B reader RF gate 



5.7.2.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.3.2. 



RQ10.28 



Registry parameters whicli are in tlie range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



RQ10.29 



The registry is not persistent. 



RQ10.30 



The values are updated after each target activation. 



RQ10.31 



The CLF shall use a default value for PUPI of 'N0=0'. 



RQ10.32 



The CLF shall apply the access condition of RO for PUPI. 



RQ10.33 



The CLF shall use a default value for APPLICATION DATA of 'N1 =0'. 



RQ10.34 



The CLF shall apply the access condition of RO for APPLICATION_DATA. 



RO10.35 



The CLF shall set a default value for AFI of '00'. 



RO10.36 



The CLF shall apply the access condition of RW to AFI. 



RO10.37 



The CLF shall use a default value for HIGHER LAYER RESPONSE of 'N2=0'. 



RO10.38 



The CLF shall apply the access condition of RO to HIGHER_LAYER_RESPONSE. 



RO10.39 



The CLF shall set a default value for HIGHER LAYER DATA of 'N3=0'. 



RO10.40 



The CLF shall apply the access condition of RW to HIGHER_LAYER_DATA. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.7.2.4 



Events and subclauses 



5.7.2.4.1 



Events 



5.7.2.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.4. 



RQ10.41 



The reader RF gates shall support the EVT_READER_REOUESTED and EVT_END_OPERATION 
events. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.7.2.4.2 



EVT READER REQUESTED 



5.7.2.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.4.1. 



RQ10.42 



On receiving the EVT_READER_REQUESTED event, the CLF shall activate the RF polling (turn on the 
RF carrier). 



RO10.43 [The CLF shall accept EVT_READER_REOUESTED event on any open pipe of any reader RF gate. 
NOTE: Development of test cases for above listed RQs is FFS. 



5.7.2.4.3 



EVT END OPERATION 



5.7.2.4.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.4.2. 



RO10.58 



Upon reception of the event EVT_END_OPERATION from a host the CLF controller shall turn the 
RF field OFF if the EVT_TARGET_DISCOVERED has been previously sent to that specific host. 



NOTE: Development of test cases for RQ1 0.58 is FFS. 
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5.7.2.5 Responses 

5.7.2.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.5. 



RQ1 0.44 If command WR_XCHG_DATA is successful, response shall be ANY_OK. 



RQ10.45 



If command WR_XCHG_DATA is rejected and /or not completed, response shall be ANYEOK. 



RQ10.46 



If Application level time-out occurred, the response shall be ANY_E_TIMEOUT. 



RQ10.47 I If Target has returned an RF error the response shall be 'WR_RF_ERROR. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.7.3 Reader application gates 

5.7.3.1 Overview 

Reference: TS 102 622 [1], clause 10.3.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.3.2 Command 

5.7.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.2. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.3.3 Registry 

5.7.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.3. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.3.4 Events and subclauses 

5.7.3.4.1 Events 

5.7.3.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.4. 
There are no conformance requirements for the terminal for the referenced clause. 
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5.7.3.4.2 



EVT TARGET DISCOVERED 



5.7.3.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.4.1. 



RQ10.48 



The existence of an RF target in tlie field of the activated RF technology shall be signalled to the 
reader application gate by EVT_TARGET_DISCOVERED event. 



RQ10.49 



If there is a single target in the reader field and the activation of the target is completed then the 
value of STATUS parameter of EVT_TARGET_DISCOVERED event shall be equal to '00'. 



RQ10.50 



If there are several targets in the field irrespective of the RF technology then the value of STATUS 
parameter of EVT_TARGET_DISCOVERED event shall be equal to '03'. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.7.4 Procedures 



5.7.4.1 



Use of contactless reader application 



5.7.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.4.1. 



RQ10.51 



On receiving the EVT_READER_REQUESTED event, the GLF shall enable the RF polling. 



RO10.52 



Once RF polling is enabled, the CLF shall start the detecting of a target according to all reader RF 
gates of the host that have an open pipe. 



RO10.53 



When a target has been detected and activated, the GLF shall notify the host via the event 
EVT TARGET DISCOVERD. 



RO10.54 



If the several targets in the field then the procedure shall stop. 



RO10.55 



When the CLF receives a response from the target to a forwarded C-APDU, the reader RF gate shall 
reply in sending back an R-APDU to the reader application gate. 



RO10.56 



If an application level time-out occurs before the CLF receives a response from the target, the CLF 
shall respond to the UICC with ANY_E_TIMEOUT. 



RQ10.57 



Once the CLF responds with ANYETIMEOUT, it shall discard data received from the target 
thereafter. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.8 Connectivity 



5.8.1 Overview 

Reference: TS 102 622 [1], clause 11.1. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.2 Connectivity gate and subclauses 
5.8.2.1 Connectivity gate 

Reference: TS 102 622 [1], clause 11.2. 
There are no conformance requirements for the Terminal Host for the referenced clause. 
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5.8.2.2 Commands 

5.8.2.2.1 PRO_HOST_REQUEST 

5.8.2.2.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.1.1. 



RQ11.1 



When the Terminal Host receives an PRO_HOST_REQUEST, it shall attempt to activate every host in 
the list of host identifiers during the Activation Duration. 



RQ11.2 



If every requested host has successfully been activated, the Terminal Host shall send an ANY_OK 
response with no parameters. 



RQ11.3 



If no requested host has been successfully activated, the Terminal Host shall send a response which is 
not ANY OK. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.8.2.3 Events and subclauses 

5.8.2.3.1 Events 

Reference: TS 102 622 [1], clause 11.2.2. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.2.3.2 EVT_CONNECTIVITY 

5.8.2.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.2.1. 



RQ1 1 .4 



When the Terminal Host receives an EVT_CONNECTIVITY, it shall send a "HCI connectivity event" as 
defined in TS 102 223 [3]. 



NOTE: Development of test cases for above listed ROs is FFS. 



5.8.2.3.3 Void 

Reference: TS 102 622 [1], clause 11.2.2.2. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.2.3.4 EVT_OPERATION_ENDED 

5.8.2.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.2.3. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.2.3.5 EVT_TRANSACTION 

5.8.2.3.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.2.4. 



RQ11.5 



When the Terminal Host receives an EVT_TRANSACTION, it shall attempt to launch an application 
associated to an NFC application in a UICC host identified by the AID. 



NOTE: Development of test cases for above listed ROs is FFS. 
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5.8.2.4 Registry 

5.8.2.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.3. 



RQ11.6 



Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.8.3 Connectivity application gate and subclauses 

5.8.3.1 Connectivity application gate 
5.8.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.3.2 Commands 

5.8.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.1. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.3.3 Events and subclauses 

5.8.3.3.1 Events 

5.8.3.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.2. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.3.3.2 EVT_STANDBY 

5.8.3.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.2.1. 



RQ1 1 .7 [When the terminal host send EVT_STANDBY, it shall not contain parameters. 



NOTE: Development of test cases for above listed RQs is FFS. 
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5.8.3.4 Registry 

5.8.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.3. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.4 Procedures 

5.8.4.1 Use of connectivity gate 

Reference: TS 102 622 [1], clause 11.4.1. 
There are no conformance requirements for the Terminal Host for the referenced clause. 
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Annex B (informative): 

Core specification version information 

Unless otherwise specified, the versions of TS 102 622 [1] from which conformance requirements have been extracted 
are as follows: 



Release 


Latest version from which conformance requirements have been extracted 


7 


V7.8.0 


8 


V8.2.0 
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